Re: checksum error in metadata node - best way to move root fs to new drive?

Is there some simple muddling of meta data that could be done to force dup meta data on deduping SSDs? Like a simple 'random' byte repeated often enough it would defeat any sane dedup? I know it would waste data but clearly that is considered worth it with dup metadata (what is the difference

Re: checksum error in metadata node - best way to move root fs to new drive?

Dave T posted on Wed, 10 Aug 2016 18:01:44 -0400 as excerpted: > Does anyone have any thoughts about using dup mode for metadata on a > Samsung 950 Pro (or any NVMe drive)? The biggest problem with dup on ssds is that some ssds (particularly the ones with the sandforce controllers) do dedup, so

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On Wed, Aug 10, 2016 at 02:46:27PM -0400, Josef Bacik wrote: > On 08/10/2016 02:25 PM, Linus Torvalds wrote: > > On Wed, Aug 10, 2016 at 11:22 AM, Josef Bacik wrote: > > > On 08/10/2016 02:06 PM, Linus Torvalds wrote: > > > > > > > > More information in the original email on lkml.

Re: BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists

This block device is a volume which is on hardware RAID. We have a few machines like this running without issue. Something odd hit this one. # free -m total used free sharedbuffers cached Mem: 32143 1258 30885 1 52

enospc after btrfs-convert(ed) ext4 volume

https://bugzilla.kernel.org/show_bug.cgi?id=151921 btrfs-progs 4.6.1 kernel-4.8.0-0.rc1.git0.1.fc25.x86_64 Details in the bug, which also includes btrfs-debug-tree and btrfs-image. I haven't tried to reproduce, so it could be a one off, and there's no enospc_debug mount option used. -- Chris

Re: checksum error in metadata node - best way to move root fs to new drive?

Apologies. I have to make a correction to the message I just sent. Disregard that message and use this one: On Wed, Aug 10, 2016 at 5:15 PM, Chris Murphy wrote: > 1. Report 'btrfs check' without --repair, let's see what it complains > about and if it might be able to

Re: checksum error in metadata node - best way to move root fs to new drive?

see below On Wed, Aug 10, 2016 at 5:15 PM, Chris Murphy wrote: > 1. Report 'btrfs check' without --repair, let's see what it complains > about and if it might be able to plausibly fix this. First, a small part of the dmesg output: [ 172.772283] Btrfs loaded [

Re: btrfs dev del hangs on 4.7

On Tue, Aug 09, 2016 at 07:41:42PM +, Hugo Mills wrote: > On Tue, Aug 09, 2016 at 03:22:03PM -0400, Chris Mason wrote: > > > > > > On 08/09/2016 03:11 PM, Hugo Mills wrote: > > >On Tue, Aug 09, 2016 at 06:27:33PM +, Hugo Mills wrote: > > >>On Tue, Aug 09, 2016 at 02:26:14PM -0400, Chris

Re: checksum error in metadata node - best way to move root fs to new drive?

On Wed, Aug 10, 2016 at 4:01 PM, Dave T wrote: > I will be very disappointed if I cannot use btrfs + dm-crypt. As far > as I can see, there is no alternative given that I need to use > snapshots (and LVM, as good as it is, has severe performance penalties > for its

Re: checksum error in metadata node - best way to move root fs to new drive?

Thanks for all the responses, guys! I really appreciate it. This information is very helpful. I will be working through the suggestions (e.g., check without repair) for the next hour or so. I'll report back when I have something to report. My drive is a Samsung 950 Pro nvme drive, which in most

Re: [PATCH 2/2] writeback: allow for dirty metadata accounting

Hello, Josef. On Wed, Aug 10, 2016 at 05:16:03PM -0400, Josef Bacik wrote: > > It bothers me a bit that sb's can actually be off bdi->sb_list while > > sb_list_lock is released. Can we make this explicit? e.g. keep > > separate bdi sb list for sb's pending metadata writeout (like b_dirty) > >

Re: [PATCH 2/2] writeback: allow for dirty metadata accounting

On Tue 09-08-16 15:08:27, Josef Bacik wrote: > Provide a mechanism for file systems to indicate how much dirty metadata they > are holding. This introduces a few things > > 1) Zone stats for dirty metadata, which is the same as the NR_FILE_DIRTY. > 2) WB stat for dirty metadata. This way we

Re: [PATCH 2/2] writeback: allow for dirty metadata accounting

On 08/10/2016 04:12 PM, Tejun Heo wrote: Hello, Josef. On Tue, Aug 09, 2016 at 03:08:27PM -0400, Josef Bacik wrote: Provide a mechanism for file systems to indicate how much dirty metadata they are holding. This introduces a few things 1) Zone stats for dirty metadata, which is the same as

Re: memory overflow or undeflow in free space tree / space_info?

Hi Josef, same again with chris next branch: ERROR: error during balancing '/vmbackup/': No space left on device There may be more info in syslog - try dmesg | tail Dumping filters: flags 0x7, state 0x0, force is off DATA (flags 0x2): balancing, usage=5 METADATA (flags 0x2): balancing,

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On Tue, Aug 9, 2016 at 10:39 PM, kernel test robot wrote: > > [ 1537.558739] nfsd: last server has exited, flushing export cache > [ 1540.627795] BUG: Dentry 880027d7c540{i=1846f,n=0a} still in use (1) > [unmount of btrfs vda] > [ 1540.633915] [ cut here

Re: checksum error in metadata node - best way to move root fs to new drive?

On Tue, Aug 9, 2016 at 9:27 PM, Dave T wrote: > btrfs scrub returned with uncorrectable errors. Searching in dmesg > returns the following information: > > BTRFS warning (device dm-0): checksum error at logical N on > /dev/mapper/[crypto] sector: y metadata node

Re: checksum error in metadata node - best way to move root fs to new drive?

I'm using LUKS, aes xts-plain64, on six devices. One is using mixed-bg single device. One is dsingle mdup. And then 2x2 mraid1 draid1. I've had zero problems. The two computers these run on do have aesni support. Aging wise, they're all at least a year old. But I've been using Btrfs on LUKS for

Re: BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists

Am 10.08.2016 um 13:16 schrieb Matt McKinnon: > I performed a quick balance which gave me: > > [39020.030638] BTRFS info (device sda1): relocating block group > 25428383236096 flags 1 > [39020.206097] BTRFS warning (device sda1): block group 23113395863552 > has wrong amount of free space >

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On Wed, Aug 10, 2016 at 11:22 AM, Josef Bacik wrote: > On 08/10/2016 02:06 PM, Linus Torvalds wrote: >> >> More information in the original email on lkml. > > I'm not subscribed to lkml and for some reason I can't find the original > email in any of the lkml/linux-nfs archives.

Re: [PATCH 2/2] writeback: allow for dirty metadata accounting

Hello, Josef. On Tue, Aug 09, 2016 at 03:08:27PM -0400, Josef Bacik wrote: > Provide a mechanism for file systems to indicate how much dirty metadata they > are holding. This introduces a few things > > 1) Zone stats for dirty metadata, which is the same as the NR_FILE_DIRTY. > 2) WB stat for

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On 08/10/2016 02:06 PM, Linus Torvalds wrote: On Tue, Aug 9, 2016 at 10:39 PM, kernel test robot wrote: [ 1537.558739] nfsd: last server has exited, flushing export cache [ 1540.627795] BUG: Dentry 880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

Re: [PATCH 1/2] remove mapping from balance_dirty_pages*()

On Wed 10-08-16 10:27:33, Jan Kara wrote: > On Tue 09-08-16 15:08:26, Josef Bacik wrote: > > The only reason we pass in the mapping is to get the inode in order to see > > if > > writeback cgroups is enabled, and even then it only checks the bdi and a > > super > > block flag.

[GIT PULL] Btrfs

Hi Linus, My for-linus-4.8 branch has some fixes for btrfs send/recv and fsync from Filipe and Robbie Ko: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.8 Bonus points to Filipe for already having xfstests in place for many of these. Filipe Manana (8) commits

Re: [PATCH 1/2] remove mapping from balance_dirty_pages*()

On Tue, Aug 09, 2016 at 03:08:26PM -0400, Josef Bacik wrote: > The only reason we pass in the mapping is to get the inode in order to see if > writeback cgroups is enabled, and even then it only checks the bdi and a super > block flag. balance_dirty_pages() doesn't even use the mapping. Since >

Re: checksum error in metadata node - best way to move root fs to new drive?

On 2016-08-10 02:27, Duncan wrote: Dave T posted on Tue, 09 Aug 2016 23:27:56 -0400 as excerpted: btrfs scrub returned with uncorrectable errors. Searching in dmesg returns the following information: BTRFS warning (device dm-0): checksum error at logical N on /dev/mapper/[crypto] sector:

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On Wed, Aug 10, 2016 at 11:46 AM, Josef Bacik wrote: > > So my naive fix would be something like this Bruce? Josef's patch looks ObviouslyCorrect(tm) to me now that I look at it - all the other callers of fh_compose() also seem to just drop the dentry unconditionally, knowing that

Re: BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists

Chris Murphy posted on Tue, 09 Aug 2016 20:25:39 -0600 as excerpted: > 1 size 50.93TiB used 22.67TiB path /dev/sda1 > > What is the exact nature of this block device? > > If getting this back up and running is urgent I suggest inquiring on IRC > what the next steps are. > > In the meantime I'd

Re: checksum error in metadata node - best way to move root fs to new drive?

Dave T posted on Tue, 09 Aug 2016 23:27:56 -0400 as excerpted: > btrfs scrub returned with uncorrectable errors. Searching in dmesg > returns the following information: > > BTRFS warning (device dm-0): checksum error at logical N on > /dev/mapper/[crypto] sector: y metadata node (level

Re: BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists

Hi, from what i see you have a non finished balance ongoing, since you have system and metadata DUP and single information on disk. so you should (re)run a balance for this data. sash Am 10.08.2016 um 02:17 schrieb Matt McKinnon: > -o usebackuproot worked well. > > after the file system

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On Wed, Aug 10, 2016 at 12:09 PM, J. Bruce Fields wrote: > > OK with me if you want to take it, otherwise I'll run it through my > usual tests and send you a pull request probably today or tomorrow. I'll let it go through your tree and your usual tests - it's not like this

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On Wed, 2016-08-10 at 14:46 -0400, Josef Bacik wrote: > On 08/10/2016 02:25 PM, Linus Torvalds wrote: > > > > > > On Wed, Aug 10, 2016 at 11:22 AM, Josef Bacik wrote: > > > > > > On 08/10/2016 02:06 PM, Linus Torvalds wrote: > > > > > > > > > > > > More information in the

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On Wed, Aug 10, 2016 at 11:56:15AM -0700, Linus Torvalds wrote: > On Wed, Aug 10, 2016 at 11:46 AM, Josef Bacik wrote: > > > > So my naive fix would be something like this > > Bruce? Josef's patch looks ObviouslyCorrect(tm) to me now that I look > at it - all the other callers of

Re: [PATCH 1/2] remove mapping from balance_dirty_pages*()

On Tue 09-08-16 15:08:26, Josef Bacik wrote: > The only reason we pass in the mapping is to get the inode in order to see if > writeback cgroups is enabled, and even then it only checks the bdi and a super > block flag. balance_dirty_pages() doesn't even use the mapping. Since >

Re: system locked up with btrfs-transaction consuming 100% CPU

On 2016-08-09 18:20, Dave T wrote: Thank you for the info, Duncan. I will use Alt-sysrq-s alt-sysrq-u alt-sysrq-b. This is the best description / recommendation I've read on the subject. I had read about these special key sequences before but I could never remember them and I didn't fully

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On 08/10/2016 02:25 PM, Linus Torvalds wrote: On Wed, Aug 10, 2016 at 11:22 AM, Josef Bacik wrote: On 08/10/2016 02:06 PM, Linus Torvalds wrote: More information in the original email on lkml. I'm not subscribed to lkml and for some reason I can't find the original email in

Re: BTRFS: error (device sda1) in btrfs_run_delayed_refs:2963: errno=-17 Object already exists

I performed a quick balance which gave me: [39020.030638] BTRFS info (device sda1): relocating block group 25428383236096 flags 1 [39020.206097] BTRFS warning (device sda1): block group 23113395863552 has wrong amount of free space [39020.206101] BTRFS warning (device sda1): failed to load

Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]

On 08/10/2016 02:25 PM, Linus Torvalds wrote: On Wed, Aug 10, 2016 at 11:22 AM, Josef Bacik wrote: On 08/10/2016 02:06 PM, Linus Torvalds wrote: More information in the original email on lkml. I'm not subscribed to lkml and for some reason I can't find the original email in

Re: [PATCH 2/2] writeback: allow for dirty metadata accounting

On 08/10/2016 06:09 AM, Jan Kara wrote: On Tue 09-08-16 15:08:27, Josef Bacik wrote: Provide a mechanism for file systems to indicate how much dirty metadata they are holding. This introduces a few things 1) Zone stats for dirty metadata, which is the same as the NR_FILE_DIRTY. 2) WB stat for