corruption with btrfs on nocow loop file
Hello, I get corruption with btrfs in a loop device with linux-3.16.3 (https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/ for-linus applied). I never had a problem with this setup until 3.16. This happened just after unpacking a few thousand small files and reading them back with an IDE (phpstorm). The loop file is a 50GB nocow file with LUKS on it. mount options for the main btrfs filesystem: /dev/sda2 on / type btrfs (rw,noatime,compress-force=lzo,ssd,discard,noacl,space_cache) mount options for the loop device: /dev/mapper/myvolume on /mnt/volume type btrfs (rw,noatime,compress-force=lzo,ssd,noacl,space_cache) btrfsck: Checking filesystem on /dev/mapper/npoa UUID: 3a869f74-2a05-4ea2-9950-a6be5e4a9691 checking extents checking free space cache checking fs roots checking csums checking root refs found 197030750 bytes used err is 0 total csum bytes: 1245628 total tree bytes: 12992 total fs tree bytes: 127696896 total extent tree bytes: 3997696 btree space waste bytes: 22086930 file data blocks allocated: 1277382656 referenced 2252468224 Btrfs v0.20-rc1-592-ge11a9ae-dirty I also got a btrfs-image of the loop file system if needed. If more information's are needed to investigate the issue just ask. Kindly regards Jan Killius dmesg.bz2 Description: BZip2 compressed data
Re: kernel BUG at mm/page-writeback.c:2317!
Hello Josef, your patch fixed the issue. Greetings, Jan On Tue, Oct 8, 2013 at 4:20 AM, Josef Bacik jba...@fusionio.com wrote: On Tue, Oct 08, 2013 at 12:36:11AM +0200, Jan Killius wrote: Hello, I'm hitting similar bug with the patch from Lui Bo. But If I revert: 573aecafca1cf7a974231b759197a1aebcf39c2a, Btrfs: actually limit the size of delalloc range) everything works fine. Here are the 2 backtraces from my machines with 3.12-rc4: http://imgur.com/sVkjGK6,mWUtzMV#0 http://imgur.com/sVkjGK6,mWUtzMV#1 Sorry for the screenshots but It was the only way to capture the backtraces. I get the bug at the end of a 2GB scp transfer almost everytime. So I thought about it and I came up with this patch but as I was writing out the explanation I realized I was wrong in some of my assumptions. However I'd still like you to give it a whirl and see if it fixes the problem and I'll take a fresh look at it tomorrow http://paste.fedoraproject.org/44986/38119874/ Thanks, Josef -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at mm/page-writeback.c:2317!
Hello, I'm hitting similar bug with the patch from Lui Bo. But If I revert: 573aecafca1cf7a974231b759197a1aebcf39c2a, Btrfs: actually limit the size of delalloc range) everything works fine. Here are the 2 backtraces from my machines with 3.12-rc4: http://imgur.com/sVkjGK6,mWUtzMV#0 http://imgur.com/sVkjGK6,mWUtzMV#1 Sorry for the screenshots but It was the only way to capture the backtraces. I get the bug at the end of a 2GB scp transfer almost everytime. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] btrfs: lz4/lz4hc compression
Hallo, I get lots of kick the bucket messages with the newest lz4 patches. Is there any way to debug/fix this ? Here is a dmesg snippet: [34114.165731] lz4: pg_out 33 32 nr_dest, nr_out 33; len 131072 out_len 131587 hdr 8, ino 1948055 [34114.165733] ... kick the bucket [34114.166268] lz4: pg_out 33 32 nr_dest, nr_out 33; len 131072 out_len 131587 hdr 8, ino 1948055 [34114.166270] ... kick the bucket [34114.166309] lz4: pg_out 33 32 nr_dest, nr_out 33; len 131072 out_len 131518 hdr 8, ino 1948055 [34114.166312] lz4: pg_out 33 32 nr_dest, nr_out 33; len 131072 out_len 131492 hdr 8, ino 1948055 [34114.166313] ... kick the bucket [34114.166314] ... kick the bucket [34114.166330] lz4: pg_out 33 32 nr_dest, nr_out 33; len 131072 out_len 131549 hdr 8, ino 1948055 [34114.166332] ... kick the bucket [34114.166373] lz4: pg_out 33 32 nr_dest, nr_out 33; len 131072 out_len 131521 hdr 8, ino 1948055 [34114.166375] ... kick the bucket [34114.166406] lz4: pg_out 33 32 nr_dest, nr_out 33; len 131072 out_len 131565 hdr 8, ino 1948055 [34114.166409] lz4: pg_out 33 32 nr_dest, nr_out 33; len 131072 out_len 131587 hdr 8, ino 1948055 [34114.166410] ... kick the bucket [34114.166411] ... kick the bucket [34114.166687] lz4: pg_out 33 32 nr_dest, nr_out 33; len 131072 out_len 131587 hdr 8, ino 1948055 [34114.166689] ... kick the bucket [34119.160244] lz4: pg_out 33 32 nr_dest, nr_out 33; len 131072 out_len 131587 hdr 8, ino 1948044 [34119.160246] ... kick the bucket [34119.160539] lz4: pg_out 33 32 nr_dest, nr_out 33; len 131072 out_len 131587 hdr 8, ino 1948044 [34119.160540] ... kick the bucket [34119.162139] lz4: pg_out 33 32 nr_dest, nr_out 33; len 131072 out_len 131577 hdr 8, ino 1948044 [34119.162144] ... kick the bucket -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
storing metadata on a dedicated device
Hello, I just wanted to ask if storing metadata on a dedicated device is implemented at the moment ? It's listed under Project ideas and there is supposed to be a patch but I can't find it anywhere. Greetings Jan Killius -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
