kernel BUG at fs/btrfs/volumes.c:2733
Hello all, I can't seem to balance my btrfs filesystem. It segfaults, and gives a kernel bug: [ 1355.139099] [ cut here ] [ 1355.139099] kernel BUG at fs/btrfs/volumes.c:2733! [ 1355.149322] Internal error: Oops - BUG: 0 [#1] SMP [ 1355.149322] Modules linked in: [ 1355.154479] CPU: 0Not tainted (3.3.0 #8) [ 1355.162109] PC is at btrfs_balance+0x312/0xb04 [ 1355.166778] LR is at btrfs_run_delayed_iputs+0x2d/0xac [ 1355.166931] pc : [c0138c3a]lr : [c01234d5]psr: 6033 [ 1355.166931] sp : cb141d98 ip : fp : be83fdb4 [ 1355.166931] r10: r9 : r8 : [ 1355.184173] r7 : r6 : ffef r5 : ede7f000 r4 : ed730e00 [ 1355.189636] r3 : r2 : r1 : r0 : 0007 [ 1355.203277] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user [ 1355.203277] Control: 50c5387d Table: 8b15c04a DAC: 0015 [ 1355.203277] Process btrfs (pid: 1798, stack limit = 0xcb1402f8) [ 1355.203277] Stack: (0xcb141d98 to 0xcb142000) [ 1355.203277] 1d80: c145f944 [ 1355.227691] 1da0: 0003 ee478d40 0015 [ 1355.227691] 1dc0: [ 1355.253356] 1de0: ede7fcd4 ede7fcd8 [ 1355.253356] 1e00: 271aee1c 000200da c0160fd5 [ 1355.253356] 1e20: ed74ec00 d6257680 ed730e00 ede7f4e8 ede7fcb0 [ 1355.279022] 1e40: ede7f000 be83fdb4 c013d489 eec9c118 be83ebf8 ed74ec00 eec8a370 [ 1355.279022] 1e60: d6257680 eec8a528 be83fdb4 c013fc6b 001d 00eb [ 1355.279022] 1e80: 0007 0001 e6f7e680 c015cecd cb141ea4 cb141ef0 [ 1355.296142] 1ea0: cb15c000 01ff 0001 eeabaac0 0001 [ 1355.296142] 1ec0: ed5428c0 c1414788 d6257688 00eb cb141ef0 c016011b cb141ef0 [ 1355.321807] 1ee0: 0001 c016018f 0817 0001 271aee1c ede92250 d6257680 [ 1355.321807] 1f00: be83ebf8 be83ebf8 eec8a528 cb14 be83fdb4 c0088075 [ 1355.321807] 1f20: 4000 c00887ff [ 1355.338928] 1f40: 271aee1c 0003 d6257680 [ 1355.338928] 1f60: be83ebf8 5000940c d6257680 be83ebf8 5000940c 0003 cb14 [ 1355.364593] 1f80: c008885d 0003 be83fec7 0003 0013c478 0036 [ 1355.364593] 1fa0: c000c5a4 c000c401 be83fec7 0003 0003 5000940c be83ebf8 be83fbf8 [ 1355.364593] 1fc0: be83fec7 0003 0013c478 0036 0002 b7ad 0001 be83fdb4 [ 1355.381713] 1fe0: 00024b3d be83ebf0 b7f7 b6ea7f9c 8010 0003 00052d17 00090224 [ 1355.381713] [c0138c3a] (btrfs_balance+0x312/0xb04) from [c013d489] (btrfs_ioctl_balance+0x109/0x174) [ 1355.381713] [c013d489] (btrfs_ioctl_balance+0x109/0x174) from [c013fc6b] (btrfs_ioctl+0xbf5/0xd42) [ 1355.418518] [c013fc6b] (btrfs_ioctl+0xbf5/0xd42) from [c0088075] (vfs_ioctl+0xd/0x28) [ 1355.418518] [c0088075] (vfs_ioctl+0xd/0x28) from [c00887ff] (do_vfs_ioctl+0x35d/0x38e) [ 1355.427093] [c00887ff] (do_vfs_ioctl+0x35d/0x38e) from [c008885d] (sys_ioctl+0x2d/0x44) [ 1355.88] [c008885d] (sys_ioctl+0x2d/0x44) from [c000c401] (ret_fast_syscall+0x1/0x44) [ 1355.88] Code: d107 f116 0f11 d100 (de02) 4620 [ 1355.458343] ---[ end trace f06b6b8fcd08e6d5 ]--- A new 'btrfs filesystem balance /' seems to just hang, and is unkillable. After a reboot, I tried again, with the same result: [ 81.048767] [ cut here ] [ 81.053619] kernel BUG at fs/btrfs/volumes.c:2733! [ 81.053619] Internal error: Oops - BUG: 0 [#1] SMP [ 81.059295] Modules linked in: [ 81.059295] CPU: 1Not tainted (3.3.0 #8) [ 81.071411] PC is at btrfs_balance+0x312/0xb04 [ 81.074890] LR is at btrfs_run_delayed_iputs+0x2d/0xac [ 81.074890] pc : [c0138c3a]lr : [c01234d5]psr: 6133 [ 81.074890] sp : edda5d98 ip : fp : beb62d64 [ 81.093475] r10: r9 : r8 : [ 81.098327] r7 : r6 : ffef r5 : ed73f000 r4 : ee311c00 [ 81.098327] r3 : r2 : r1 : r0 : 0007 [ 81.112609] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user [ 81.112609] Control: 50c5387d Table: a7fb404a DAC: 0015 [ 81.112609] Process btrfs (pid: 752, stack limit = 0xedda42f8) [ 81.132354] Stack: (0xedda5d98 to 0xedda6000) [ 81.132354] 5d80: c145f944 [ 81.145477] 5da0: 0003 eeabca40 0015 [ 81.145477] 5dc0: [ 81.145477] 5de0:
R: Re: Create subvolume from a directory?
Hi Liubo Messaggio originale Da: liubo2...@cn.fujitsu.com Data: 29/03/2012 3.24 Could you elaborate which would be the issue ? cp --reflink-ing a file is not different than snapshotting a file. In any case I could mount a snapshot and not the source subvolume. We already have a debate about this cross-link device: http://comments.gmane.org/gmane.comp.file-systems.btrfs/9864 I read the thread, but I didn't find any explanation for which it should be dangerous allowing a cross-link device cp--reflink. Christoph Hellwig only asked to explain the btrfs subvolume semantics to the fsdevel mailing list, in order to find possible conflict with the standard unix semantics. But because the Inode are different from source and dest I cannot see any problem (may be I am wrong, but please explain why). The only fact that should be pointed out is that cross-link device is not possible in the general case; btrfs would be an exception. But I think that there are very good reasons to allow the btrfs-exception. But, I repeat, I didn't find any good reason to do not allow it. cp --reflink will use clone feature, which can share data among files, but metadata is preserved individually. My case is that I can mount both a subvolume and a snapshot via -o subvol=xxx or -o subvolid=xxx. This should not be a problem. My usual setup is to mount a subvolume as root, and the real btrfs root inside a subdirectory to allow operation between subvolume (like snapshot and/or cp --reflink). Of course if I don't mount the btrfs root, I could not perform snapshot and/or cp --reflink. thanks, liubo Ciao Goffredo -- 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 fs/btrfs/volumes.c:2733
On Thu, Mar 29, 2012 at 12:52:35PM +0200, Sander wrote: Hello all, I can't seem to balance my btrfs filesystem. It segfaults, and gives a kernel bug: [ 1355.139099] [ cut here ] [ 1355.139099] kernel BUG at fs/btrfs/volumes.c:2733! [ 1355.149322] Internal error: Oops - BUG: 0 [#1] SMP [ 1355.149322] Modules linked in: [ 1355.154479] CPU: 0Not tainted (3.3.0 #8) [ 1355.162109] PC is at btrfs_balance+0x312/0xb04 [ 1355.166778] LR is at btrfs_run_delayed_iputs+0x2d/0xac [ 1355.166931] pc : [c0138c3a]lr : [c01234d5]psr: 6033 [ 1355.166931] sp : cb141d98 ip : fp : be83fdb4 [ 1355.166931] r10: r9 : r8 : [ 1355.184173] r7 : r6 : ffef r5 : ede7f000 r4 : ed730e00 [ 1355.189636] r3 : r2 : r1 : r0 : 0007 [ 1355.203277] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user [ 1355.203277] Control: 50c5387d Table: 8b15c04a DAC: 0015 [ 1355.203277] Process btrfs (pid: 1798, stack limit = 0xcb1402f8) [ 1355.203277] Stack: (0xcb141d98 to 0xcb142000) [ 1355.203277] 1d80: c145f944 [ 1355.227691] 1da0: 0003 ee478d40 0015 [ 1355.227691] 1dc0: [ 1355.253356] 1de0: ede7fcd4 ede7fcd8 [ 1355.253356] 1e00: 271aee1c 000200da c0160fd5 [ 1355.253356] 1e20: ed74ec00 d6257680 ed730e00 ede7f4e8 ede7fcb0 [ 1355.279022] 1e40: ede7f000 be83fdb4 c013d489 eec9c118 be83ebf8 ed74ec00 eec8a370 [ 1355.279022] 1e60: d6257680 eec8a528 be83fdb4 c013fc6b 001d 00eb [ 1355.279022] 1e80: 0007 0001 e6f7e680 c015cecd cb141ea4 cb141ef0 [ 1355.296142] 1ea0: cb15c000 01ff 0001 eeabaac0 0001 [ 1355.296142] 1ec0: ed5428c0 c1414788 d6257688 00eb cb141ef0 c016011b cb141ef0 [ 1355.321807] 1ee0: 0001 c016018f 0817 0001 271aee1c ede92250 d6257680 [ 1355.321807] 1f00: be83ebf8 be83ebf8 eec8a528 cb14 be83fdb4 c0088075 [ 1355.321807] 1f20: 4000 c00887ff [ 1355.338928] 1f40: 271aee1c 0003 d6257680 [ 1355.338928] 1f60: be83ebf8 5000940c d6257680 be83ebf8 5000940c 0003 cb14 [ 1355.364593] 1f80: c008885d 0003 be83fec7 0003 0013c478 0036 [ 1355.364593] 1fa0: c000c5a4 c000c401 be83fec7 0003 0003 5000940c be83ebf8 be83fbf8 [ 1355.364593] 1fc0: be83fec7 0003 0013c478 0036 0002 b7ad 0001 be83fdb4 [ 1355.381713] 1fe0: 00024b3d be83ebf0 b7f7 b6ea7f9c 8010 0003 00052d17 00090224 [ 1355.381713] [c0138c3a] (btrfs_balance+0x312/0xb04) from [c013d489] (btrfs_ioctl_balance+0x109/0x174) [ 1355.381713] [c013d489] (btrfs_ioctl_balance+0x109/0x174) from [c013fc6b] (btrfs_ioctl+0xbf5/0xd42) [ 1355.418518] [c013fc6b] (btrfs_ioctl+0xbf5/0xd42) from [c0088075] (vfs_ioctl+0xd/0x28) [ 1355.418518] [c0088075] (vfs_ioctl+0xd/0x28) from [c00887ff] (do_vfs_ioctl+0x35d/0x38e) [ 1355.427093] [c00887ff] (do_vfs_ioctl+0x35d/0x38e) from [c008885d] (sys_ioctl+0x2d/0x44) [ 1355.88] [c008885d] (sys_ioctl+0x2d/0x44) from [c000c401] (ret_fast_syscall+0x1/0x44) [ 1355.88] Code: d107 f116 0f11 d100 (de02) 4620 [ 1355.458343] ---[ end trace f06b6b8fcd08e6d5 ]--- A new 'btrfs filesystem balance /' seems to just hang, and is unkillable. After a reboot, I tried again, with the same result: [ 81.048767] [ cut here ] [ 81.053619] kernel BUG at fs/btrfs/volumes.c:2733! [ 81.053619] Internal error: Oops - BUG: 0 [#1] SMP [ 81.059295] Modules linked in: [ 81.059295] CPU: 1Not tainted (3.3.0 #8) [ 81.071411] PC is at btrfs_balance+0x312/0xb04 [ 81.074890] LR is at btrfs_run_delayed_iputs+0x2d/0xac [ 81.074890] pc : [c0138c3a]lr : [c01234d5]psr: 6133 [ 81.074890] sp : edda5d98 ip : fp : beb62d64 [ 81.093475] r10: r9 : r8 : [ 81.098327] r7 : r6 : ffef r5 : ed73f000 r4 : ee311c00 [ 81.098327] r3 : r2 : r1 : r0 : 0007 [ 81.112609] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user [ 81.112609] Control: 50c5387d Table: a7fb404a DAC: 0015 [ 81.112609] Process btrfs (pid: 752, stack limit = 0xedda42f8) [ 81.132354] Stack: (0xedda5d98 to 0xedda6000) [ 81.132354] 5d80: c145f944 [ 81.145477] 5da0:
Re: kernel BUG at fs/btrfs/volumes.c:2733
On Thu, Mar 29, 2012 at 12:52:35PM +0200, Sander wrote: Hello all, I can't seem to balance my btrfs filesystem. It segfaults, and gives a kernel bug: [ 1355.139099] [ cut here ] [ 1355.139099] kernel BUG at fs/btrfs/volumes.c:2733! [ 1355.149322] Internal error: Oops - BUG: 0 [#1] SMP [ 1355.149322] Modules linked in: [ 1355.154479] CPU: 0Not tainted (3.3.0 #8) [ 1355.162109] PC is at btrfs_balance+0x312/0xb04 [ 1355.166778] LR is at btrfs_run_delayed_iputs+0x2d/0xac [ 1355.166931] pc : [c0138c3a]lr : [c01234d5]psr: 6033 [ 1355.166931] sp : cb141d98 ip : fp : be83fdb4 [ 1355.166931] r10: r9 : r8 : [ 1355.184173] r7 : r6 : ffef r5 : ede7f000 r4 : ed730e00 [ 1355.189636] r3 : r2 : r1 : r0 : 0007 [ 1355.203277] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user [ 1355.203277] Control: 50c5387d Table: 8b15c04a DAC: 0015 [ 1355.203277] Process btrfs (pid: 1798, stack limit = 0xcb1402f8) [ 1355.203277] Stack: (0xcb141d98 to 0xcb142000) [ 1355.203277] 1d80: c145f944 [ 1355.227691] 1da0: 0003 ee478d40 0015 [ 1355.227691] 1dc0: [ 1355.253356] 1de0: ede7fcd4 ede7fcd8 [ 1355.253356] 1e00: 271aee1c 000200da c0160fd5 [ 1355.253356] 1e20: ed74ec00 d6257680 ed730e00 ede7f4e8 ede7fcb0 [ 1355.279022] 1e40: ede7f000 be83fdb4 c013d489 eec9c118 be83ebf8 ed74ec00 eec8a370 [ 1355.279022] 1e60: d6257680 eec8a528 be83fdb4 c013fc6b 001d 00eb [ 1355.279022] 1e80: 0007 0001 e6f7e680 c015cecd cb141ea4 cb141ef0 [ 1355.296142] 1ea0: cb15c000 01ff 0001 eeabaac0 0001 [ 1355.296142] 1ec0: ed5428c0 c1414788 d6257688 00eb cb141ef0 c016011b cb141ef0 [ 1355.321807] 1ee0: 0001 c016018f 0817 0001 271aee1c ede92250 d6257680 [ 1355.321807] 1f00: be83ebf8 be83ebf8 eec8a528 cb14 be83fdb4 c0088075 [ 1355.321807] 1f20: 4000 c00887ff [ 1355.338928] 1f40: 271aee1c 0003 d6257680 [ 1355.338928] 1f60: be83ebf8 5000940c d6257680 be83ebf8 5000940c 0003 cb14 [ 1355.364593] 1f80: c008885d 0003 be83fec7 0003 0013c478 0036 [ 1355.364593] 1fa0: c000c5a4 c000c401 be83fec7 0003 0003 5000940c be83ebf8 be83fbf8 [ 1355.364593] 1fc0: be83fec7 0003 0013c478 0036 0002 b7ad 0001 be83fdb4 [ 1355.381713] 1fe0: 00024b3d be83ebf0 b7f7 b6ea7f9c 8010 0003 00052d17 00090224 [ 1355.381713] [c0138c3a] (btrfs_balance+0x312/0xb04) from [c013d489] (btrfs_ioctl_balance+0x109/0x174) [ 1355.381713] [c013d489] (btrfs_ioctl_balance+0x109/0x174) from [c013fc6b] (btrfs_ioctl+0xbf5/0xd42) [ 1355.418518] [c013fc6b] (btrfs_ioctl+0xbf5/0xd42) from [c0088075] (vfs_ioctl+0xd/0x28) [ 1355.418518] [c0088075] (vfs_ioctl+0xd/0x28) from [c00887ff] (do_vfs_ioctl+0x35d/0x38e) [ 1355.427093] [c00887ff] (do_vfs_ioctl+0x35d/0x38e) from [c008885d] (sys_ioctl+0x2d/0x44) [ 1355.88] [c008885d] (sys_ioctl+0x2d/0x44) from [c000c401] (ret_fast_syscall+0x1/0x44) [ 1355.88] Code: d107 f116 0f11 d100 (de02) 4620 [ 1355.458343] ---[ end trace f06b6b8fcd08e6d5 ]--- A new 'btrfs filesystem balance /' seems to just hang, and is unkillable. After a reboot, I tried again, with the same result: [ 81.048767] [ cut here ] [ 81.053619] kernel BUG at fs/btrfs/volumes.c:2733! [ 81.053619] Internal error: Oops - BUG: 0 [#1] SMP [ 81.059295] Modules linked in: [ 81.059295] CPU: 1Not tainted (3.3.0 #8) [ 81.071411] PC is at btrfs_balance+0x312/0xb04 [ 81.074890] LR is at btrfs_run_delayed_iputs+0x2d/0xac [ 81.074890] pc : [c0138c3a]lr : [c01234d5]psr: 6133 [ 81.074890] sp : edda5d98 ip : fp : beb62d64 [ 81.093475] r10: r9 : r8 : [ 81.098327] r7 : r6 : ffef r5 : ed73f000 r4 : ee311c00 [ 81.098327] r3 : r2 : r1 : r0 : 0007 [ 81.112609] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user [ 81.112609] Control: 50c5387d Table: a7fb404a DAC: 0015 [ 81.112609] Process btrfs (pid: 752, stack limit = 0xedda42f8) [ 81.132354] Stack: (0xedda5d98 to 0xedda6000) [ 81.132354] 5d80: c145f944 [ 81.145477] 5da0:
Re: [PATCH 10/10] Btrfs: drop cache with VACANCY em when we fail to start a transaction
On Tue, Mar 27, 2012 at 02:44:38PM +0800, Liu Bo wrote: We need to clean a VACANCY em(if we have) when we fail to start a transaction. Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com --- fs/btrfs/inode.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index bacf441..2b2f0b6 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3406,9 +3406,6 @@ int btrfs_cont_expand(struct inode *inode, loff_t oldsize, loff_t size) break; } - btrfs_drop_extent_cache(inode, hole_start, - last_byte - 1, 0); - btrfs_update_inode(trans, root, inode); btrfs_end_transaction(trans, root); } @@ -3419,6 +3416,9 @@ int btrfs_cont_expand(struct inode *inode, loff_t oldsize, loff_t size) break; } + if (em test_bit(EXTENT_FLAG_VACANCY, em-flags)) + btrfs_drop_extent_cache(inode, hole_start, last_byte - 1, 0); + Hmmm, last_byte isn't always setup at this point (uninit variable). I'm a little uncertain about what this one is fixing? -chris -- 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 fs/btrfs/volumes.c:2733
Hello Josef, Josef Bacik wrote (ao): On Thu, Mar 29, 2012 at 12:52:35PM +0200, Sander wrote: I can't seem to balance my btrfs filesystem. It segfaults, and gives a kernel bug: [ 1355.139099] [ cut here ] [ 1355.139099] kernel BUG at fs/btrfs/volumes.c:2733! [ 1355.149322] Internal error: Oops - BUG: 0 [#1] SMP [ 1355.149322] Modules linked in: [ 1355.154479] CPU: 0Not tainted (3.3.0 #8) [ 1355.162109] PC is at btrfs_balance+0x312/0xb04 [ 1355.166778] LR is at btrfs_run_delayed_iputs+0x2d/0xac The system is a pandaboard running a plain Linus kernel 3.3.0 with a btrfs filesystem, over two Intel 320 600GB ssd's, connected via usb (on an usb hub), on top of md_crypt. Mount options: subvol=rootvolume,space_cache,inode_cache,compress=lzo,ssd Before the balance, I deleted about 2500 snapshots and waited for the btrfs kernel threads to calm down. Then I initiated a btrfs filesystem scrub. Unfortunately during the scrub, the filesystem balance started. Might be related. Well that's kind of cool. So 2 options 1) If you are in a hurry and need this stuff back right away run btrfs fi balance resume / and it should work, buuutt 2) If you aren't in a hurry I'd really like to try and reproduce this locally and if I can't I'd like to be able to send you patches to help me figure out how to fix this problem. I am in no hurry at all. The filesystem seems just fine the way it is (after a reboot), so there is no stuff to get back right away. Does the kernel bug suggest the filesystem is fubar? I'll keep the filesystem as is (no resume) and am happy to test any patches you have. Sander -- Humilis IT Services and Solutions http://www.humilis.net -- 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 fs/btrfs/volumes.c:2733
On Thu, Mar 29, 2012 at 05:14:22PM +0200, Sander wrote: Ilya Dryomov wrote (ao): On Thu, Mar 29, 2012 at 12:52:35PM +0200, Sander wrote: After a reboot, I tried again, with the same result: [ 81.048767] [ cut here ] [ 81.053619] kernel BUG at fs/btrfs/volumes.c:2733! [ 81.053619] Internal error: Oops - BUG: 0 [#1] SMP [ 81.059295] Modules linked in: [ 81.059295] CPU: 1Not tainted (3.3.0 #8) [ 81.071411] PC is at btrfs_balance+0x312/0xb04 [ 81.074890] LR is at btrfs_run_delayed_iputs+0x2d/0xac So you have balance item on disk, but the kernel doesn't seem to know about it in advance, which is odd and so when you try to run balance it panics on one of the safety checks. The system is a pandaboard running a plain Linus kernel 3.3.0 with a btrfs filesystem, over two Intel 320 600GB ssd's, connected via usb (on an usb hub), on top of md_crypt. Mount options: subvol=rootvolume,space_cache,inode_cache,compress=lzo,ssd Before the balance, I deleted about 2500 snapshots and waited for the btrfs kernel threads to calm down. Then I initiated a btrfs filesystem scrub. Unfortunately during the scrub, the filesystem balance started. Might be related. That's indeed pretty cool, I wonder how that could happen. I create 5 snapshots of 5 different subvolumes every 5 minutes, and the system is low on memory: total used free sharedbuffers cached Mem: 745712 33 0 0480 -/+ buffers/cache:231514 Swap:0 0 0 There is ample space on the fileystem: panda:~# df -h / Filesystem Size Used Avail Use% Mounted on /dev/mapper/ata-INTEL_SSDSA2CW600G3_CVPR112405AJ600FGN 1.1T 17G 1.1T 2% / panda:~# btrfs filesystem df / Data, RAID0: total=24.00GB, used=15.69GB System, RAID1: total=64.00MB, used=12.00KB System: total=4.00MB, used=0.00 Metadata, RAID1: total=23.00GB, used=231.26MB Do you need more information? No, that's enough for now. I'm definitely intrested in reproducing it. Could you please umount this filesystem, capture the output of 'btrfs-debug-tree -d dev' and post it somewhere ? Will do. It is the / filesystem, so I'll need to reboot. I need this to confirm that balance item is on disk. After that mount it back and see if there is btrfs: continuing balance line in dmesg (and if btrfs-balance kthread shows up)? There was none after the first reboot, but I'll pay extra attention to that after the next reboot. If so, just let it run, it should finish the balance and remove on-disk item. (You can query the status of running balance with 'btrfs balance status mnt') Do I need newer tools for that? This is Debian Sid (unstable): Yeah, you do. That command is in master now, but it's not really needed. If btrfs-balance shows up, just wait for it to finish, it should get rid of the balance item. If it doesn't show up but the item is there we will have to dig deeper. Thanks, Ilya -- 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 fs/btrfs/volumes.c:2733
On Thu, Mar 29, 2012 at 04:39:29PM +0200, Sander wrote: Hello Josef, Josef Bacik wrote (ao): On Thu, Mar 29, 2012 at 12:52:35PM +0200, Sander wrote: I can't seem to balance my btrfs filesystem. It segfaults, and gives a kernel bug: [ 1355.139099] [ cut here ] [ 1355.139099] kernel BUG at fs/btrfs/volumes.c:2733! [ 1355.149322] Internal error: Oops - BUG: 0 [#1] SMP [ 1355.149322] Modules linked in: [ 1355.154479] CPU: 0Not tainted (3.3.0 #8) [ 1355.162109] PC is at btrfs_balance+0x312/0xb04 [ 1355.166778] LR is at btrfs_run_delayed_iputs+0x2d/0xac The system is a pandaboard running a plain Linus kernel 3.3.0 with a btrfs filesystem, over two Intel 320 600GB ssd's, connected via usb (on an usb hub), on top of md_crypt. Mount options: subvol=rootvolume,space_cache,inode_cache,compress=lzo,ssd Before the balance, I deleted about 2500 snapshots and waited for the btrfs kernel threads to calm down. Then I initiated a btrfs filesystem scrub. Unfortunately during the scrub, the filesystem balance started. Might be related. Well that's kind of cool. So 2 options 1) If you are in a hurry and need this stuff back right away run btrfs fi balance resume / and it should work, buuutt 2) If you aren't in a hurry I'd really like to try and reproduce this locally and if I can't I'd like to be able to send you patches to help me figure out how to fix this problem. I am in no hurry at all. The filesystem seems just fine the way it is (after a reboot), so there is no stuff to get back right away. Does the kernel bug suggest the filesystem is fubar? No, as I said in another mail you are trapping over a simle sanity check. FS should be OK. Thanks, Ilya -- 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
btrfsck integration with userlevel API for fsck
Are there plans to integrate btrfsck with the userlevel API for fsck? AFAIK, it currently does not work as such (i.e. `shutdown -rF now` does not trigger a check on the next boot). What is the recommended method to check a btrfs root filesystem? Live media? -- 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 10/10] Btrfs: drop cache with VACANCY em when we fail to start a transaction
On 03/29/2012 10:01 PM, Chris Mason wrote: On Tue, Mar 27, 2012 at 02:44:38PM +0800, Liu Bo wrote: We need to clean a VACANCY em(if we have) when we fail to start a transaction. Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com --- fs/btrfs/inode.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index bacf441..2b2f0b6 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -3406,9 +3406,6 @@ int btrfs_cont_expand(struct inode *inode, loff_t oldsize, loff_t size) break; } -btrfs_drop_extent_cache(inode, hole_start, -last_byte - 1, 0); - btrfs_update_inode(trans, root, inode); btrfs_end_transaction(trans, root); } @@ -3419,6 +3416,9 @@ int btrfs_cont_expand(struct inode *inode, loff_t oldsize, loff_t size) break; } +if (em test_bit(EXTENT_FLAG_VACANCY, em-flags)) +btrfs_drop_extent_cache(inode, hole_start, last_byte - 1, 0); + Hmmm, last_byte isn't always setup at this point (uninit variable). I'm a little uncertain about what this one is fixing? err, sorry, plz drop this one, it's just a cleanup. I was just thinking when we create a VACANCY em and fail to start a transaction(break out from while loop), we'll leave a VACANCY em behind. thanks, liubo -chris -- 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 -- 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: btrfsck integration with userlevel API for fsck
On Fri, Mar 30, 2012 at 5:08 AM, member graysky gray...@archlinux.us wrote: Are there plans to integrate btrfsck with the userlevel API for fsck? There isn't even a stable, working, fixing btrfsck yet :) AFAIK, it currently does not work as such (i.e. `shutdown -rF now` does not trigger a check on the next boot). What is the recommended method to check a btrfs root filesystem? Live media? Currently? None. Set the last part of root line in fstab to 0 to disable fsck. Newer kernels should be smart enough to recover from unclean shutdown automatically, kinda like what zfs does, or what ext3/4 does with its journal replay. -- Fajar -- 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
