I''ve been using btrfs for a while as my /home (converted from ext4; encrypted lvm) when it died on me. Mounting it crashes immediately, here''s a log: [ 6.455721] ------------[ cut here ]------------ [ 6.456117] kernel BUG at fs/btrfs/inode.c:4586! [ 6.456117] invalid opcode: 0000 [#1] SMP [ 6.456117] CPU 0 [ 6.456117] Modules linked in: btrfs zlib_deflate libcrc32c [ 6.456117] [ 6.456117] Pid: 243, comm: mount Not tainted 2.6.40.3-0.fc15.x86_64 #1 Bochs Bochs [ 6.456117] RIP: 0010:[<ffffffffa0035642>] [<ffffffffa0035642>] btrfs_add_link+0x123/0x17c [btrfs] [ 6.456117] RSP: 0018:ffff880007ac9838 EFLAGS: 00010282 [ 6.456117] RAX: 00000000ffffffef RBX: ffff880003ec3938 RCX: 0000000000000ed7 [ 6.456117] RDX: 0000000000000ed6 RSI: 000060fff8e013b0 RDI: ffffea00000da3b0 [ 6.456117] RBP: ffff880007ac98a8 R08: ffffffffa00123af R09: 0000000000000b23 [ 6.456117] R10: 0000000000000b23 R11: 0000000000000002 R12: ffff880003ec3548 [ 6.456117] R13: ffff880007863000 R14: 000000000000000d R15: ffff880007798500 [ 6.456117] FS: 00007effe7241820(0000) GS:ffff880006e00000(0000) knlGS:0000000000000000 [ 6.456117] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.456117] CR2: 00007effe62cc580 CR3: 0000000007b7c000 CR4: 00000000000006f0 [ 6.456117] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 6.456117] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 6.456117] Process mount (pid: 243, threadinfo ffff880007ac8000, task ffff880002d40000) [ 6.456117] Stack: [ 6.456117] ffff880000000001 00000000000002cb ffff880007ac9878 ffff880003e5d000 [ 6.456117] 0000000000000000 3fff880002c5f000 0100000000002894 0000000000000000 [ 6.456117] 0000000000001000 ffff880003e5a120 ffff880003ec3548 ffff880007ac99c7 [ 6.456117] Call Trace: [ 6.456117] [<ffffffffa005646e>] add_inode_ref+0x2e6/0x37c [btrfs] [ 6.456117] [<ffffffffa00493f6>] ? read_extent_buffer+0xc3/0xe3 [btrfs] [ 6.456117] [<ffffffffa0056e14>] replay_one_buffer+0x197/0x212 [btrfs] [ 6.456117] [<ffffffffa0054e94>] walk_down_log_tree+0x15a/0x2c1 [btrfs] [ 6.456117] [<ffffffffa005507a>] walk_log_tree+0x7f/0x19e [btrfs] [ 6.456117] [<ffffffff8123a8d9>] ? radix_tree_lookup+0xb/0xd [ 6.456117] [<ffffffffa0058148>] btrfs_recover_log_trees+0x28b/0x298 [btrfs] [ 6.456117] [<ffffffffa0056c7d>] ? replay_one_dir_item+0xbd/0xbd [btrfs] [ 6.456117] [<ffffffffa002a192>] open_ctree+0x10f1/0x13ff [btrfs] [ 6.456117] [<ffffffffa0010861>] btrfs_mount+0x233/0x496 [btrfs] [ 6.456117] [<ffffffff810f43fc>] ? pcpu_next_pop+0x3d/0x4a [ 6.456117] [<ffffffff810f54ca>] ? pcpu_alloc+0x7f7/0x833 [ 6.456117] [<ffffffff81129b74>] mount_fs+0x69/0x155 [ 6.456117] [<ffffffff810f5516>] ? __alloc_percpu+0x10/0x12 [ 6.456117] [<ffffffff8113d905>] vfs_kern_mount+0x63/0x9d [ 6.456117] [<ffffffff8113e288>] do_kern_mount+0x4d/0xdf [ 6.456117] [<ffffffff8113f90d>] do_mount+0x63c/0x69f [ 6.456117] [<ffffffff810f1225>] ? memdup_user+0x55/0x7d [ 6.456117] [<ffffffff810f1288>] ? strndup_user+0x3b/0x51 [ 6.456117] [<ffffffff8113fbf2>] sys_mount+0x88/0xc2 [ 6.456117] [<ffffffff8148e182>] system_call_fastpath+0x16/0x1b [ 6.456117] Code: 89 f1 4c 89 fa 4c 89 ee 48 89 44 24 08 41 8b 04 24 66 c1 e8 0c 83 e0 0f 0f b6 80 78 eb 06 a0 89 04 24 e8 8c d5 fe ff 85 c0 74 02 <0f> 0b 45 01 f6 4d 63 f6 4c 03 b3 d0 00 00 00 4c 89 b3 d0 00 00 [ 6.456117] RIP [<ffffffffa0035642>] btrfs_add_link+0x123/0x17c [btrfs] [ 6.456117] RSP <ffff880007ac9838> [ 6.592232] ---[ end trace 44b5956456a7dc01 ]--- Tried btrfsck, immediate segfault. Both kernel and btrfsprogs are stock Fedora 15. I still have the logical volume and would like to recover it. Its fairly easy to try out things in a virtual machine, so if you have a patch you want me to try out, I''m here. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/23/2011 10:15 AM, Avi Kivity wrote:> I''ve been using btrfs for a while as my /home (converted from ext4; > encrypted lvm) when it died on me. Mounting it crashes immediately, > here''s a log: > > [ 6.455721] ------------[ cut here ]------------ > [ 6.456117] kernel BUG at fs/btrfs/inode.c:4586! > [ 6.456117] invalid opcode: 0000 [#1] SMP > [ 6.456117] CPU 0 > [ 6.456117] Modules linked in: btrfs zlib_deflate libcrc32c > [ 6.456117] > [ 6.456117] Pid: 243, comm: mount Not tainted > 2.6.40.3-0.fc15.x86_64 #1 Bochs Bochs > [ 6.456117] RIP: 0010:[<ffffffffa0035642>] [<ffffffffa0035642>] > btrfs_add_link+0x123/0x17c [btrfs] > [ 6.456117] RSP: 0018:ffff880007ac9838 EFLAGS: 00010282 > [ 6.456117] RAX: 00000000ffffffef RBX: ffff880003ec3938 RCX: 0000000000000ed7 > [ 6.456117] RDX: 0000000000000ed6 RSI: 000060fff8e013b0 RDI: ffffea00000da3b0 > [ 6.456117] RBP: ffff880007ac98a8 R08: ffffffffa00123af R09: 0000000000000b23 > [ 6.456117] R10: 0000000000000b23 R11: 0000000000000002 R12: ffff880003ec3548 > [ 6.456117] R13: ffff880007863000 R14: 000000000000000d R15: ffff880007798500 > [ 6.456117] FS: 00007effe7241820(0000) GS:ffff880006e00000(0000) > knlGS:0000000000000000 > [ 6.456117] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 6.456117] CR2: 00007effe62cc580 CR3: 0000000007b7c000 CR4: 00000000000006f0 > [ 6.456117] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 6.456117] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 6.456117] Process mount (pid: 243, threadinfo ffff880007ac8000, > task ffff880002d40000) > [ 6.456117] Stack: > [ 6.456117] ffff880000000001 00000000000002cb ffff880007ac9878 > ffff880003e5d000 > [ 6.456117] 0000000000000000 3fff880002c5f000 0100000000002894 > 0000000000000000 > [ 6.456117] 0000000000001000 ffff880003e5a120 ffff880003ec3548 > ffff880007ac99c7 > [ 6.456117] Call Trace: > [ 6.456117] [<ffffffffa005646e>] add_inode_ref+0x2e6/0x37c [btrfs] > [ 6.456117] [<ffffffffa00493f6>] ? read_extent_buffer+0xc3/0xe3 [btrfs] > [ 6.456117] [<ffffffffa0056e14>] replay_one_buffer+0x197/0x212 [btrfs] > [ 6.456117] [<ffffffffa0054e94>] walk_down_log_tree+0x15a/0x2c1 [btrfs] > [ 6.456117] [<ffffffffa005507a>] walk_log_tree+0x7f/0x19e [btrfs] > [ 6.456117] [<ffffffff8123a8d9>] ? radix_tree_lookup+0xb/0xd > [ 6.456117] [<ffffffffa0058148>] btrfs_recover_log_trees+0x28b/0x298 [btrfs] > [ 6.456117] [<ffffffffa0056c7d>] ? replay_one_dir_item+0xbd/0xbd [btrfs] > [ 6.456117] [<ffffffffa002a192>] open_ctree+0x10f1/0x13ff [btrfs] > [ 6.456117] [<ffffffffa0010861>] btrfs_mount+0x233/0x496 [btrfs] > [ 6.456117] [<ffffffff810f43fc>] ? pcpu_next_pop+0x3d/0x4a > [ 6.456117] [<ffffffff810f54ca>] ? pcpu_alloc+0x7f7/0x833 > [ 6.456117] [<ffffffff81129b74>] mount_fs+0x69/0x155 > [ 6.456117] [<ffffffff810f5516>] ? __alloc_percpu+0x10/0x12 > [ 6.456117] [<ffffffff8113d905>] vfs_kern_mount+0x63/0x9d > [ 6.456117] [<ffffffff8113e288>] do_kern_mount+0x4d/0xdf > [ 6.456117] [<ffffffff8113f90d>] do_mount+0x63c/0x69f > [ 6.456117] [<ffffffff810f1225>] ? memdup_user+0x55/0x7d > [ 6.456117] [<ffffffff810f1288>] ? strndup_user+0x3b/0x51 > [ 6.456117] [<ffffffff8113fbf2>] sys_mount+0x88/0xc2 > [ 6.456117] [<ffffffff8148e182>] system_call_fastpath+0x16/0x1b > [ 6.456117] Code: 89 f1 4c 89 fa 4c 89 ee 48 89 44 24 08 41 8b 04 > 24 66 c1 e8 0c 83 e0 0f 0f b6 80 78 eb 06 a0 89 04 24 e8 8c d5 fe ff > 85 c0 74 02 <0f> 0b 45 01 f6 4d 63 f6 4c 03 b3 d0 00 00 00 4c 89 b3 d0 > 00 00 > [ 6.456117] RIP [<ffffffffa0035642>] btrfs_add_link+0x123/0x17c [btrfs] > [ 6.456117] RSP <ffff880007ac9838> > [ 6.592232] ---[ end trace 44b5956456a7dc01 ]--- > > Tried btrfsck, immediate segfault. > > Both kernel and btrfsprogs are stock Fedora 15. I still have the > logical volume and would like to recover it. Its fairly easy to try > out things in a virtual machine, so if you have a patch you want me to > try out, I''m here.This is fixed upstream, I''ve sent the patch to -stable so hopefully it will show up in fedora soon, but in the meantime can you try Linus''s tree and verify that it fixes it? Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Aug 23, 2011 at 05:15:46PM +0300, Avi Kivity wrote:> I''ve been using btrfs for a while as my /home (converted from ext4; > encrypted lvm) when it died on me. Mounting it crashes immediately, > here''s a log:[...]> [ 6.456117] Call Trace: > [ 6.456117] [<ffffffffa005646e>] add_inode_ref+0x2e6/0x37c [btrfs] > [ 6.456117] [<ffffffffa00493f6>] ? read_extent_buffer+0xc3/0xe3 [btrfs] > [ 6.456117] [<ffffffffa0056e14>] replay_one_buffer+0x197/0x212 [btrfs] > [ 6.456117] [<ffffffffa0054e94>] walk_down_log_tree+0x15a/0x2c1 [btrfs] > [ 6.456117] [<ffffffffa005507a>] walk_log_tree+0x7f/0x19e [btrfs] > [ 6.456117] [<ffffffff8123a8d9>] ? radix_tree_lookup+0xb/0xd > [ 6.456117] [<ffffffffa0058148>] btrfs_recover_log_trees+0x28b/0x298 [btrfs] > [ 6.456117] [<ffffffffa0056c7d>] ? replay_one_dir_item+0xbd/0xbd [btrfs] > [ 6.456117] [<ffffffffa002a192>] open_ctree+0x10f1/0x13ff [btrfs][...]> Tried btrfsck, immediate segfault.Yes, it does that,I''m afraid. (It also doesn''t fix anything).> Both kernel and btrfsprogs are stock Fedora 15. I still have the > logical volume and would like to recover it. Its fairly easy to try > out things in a virtual machine, so if you have a patch you want me to > try out, I''m here.It looks like you''ve got a corrupt log tree. The quick and easy fix for that is on the wiki in the problem FAQ page [1]. Could you give a bit more information about what happened in the crash immediately prior to the FS being unmountable, and how your storage is configured? Hugo. [1] https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_can.27t_mount_my_filesystem.2C_and_I_get_a_kernel_oops.21 -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You stay in the theatre because you''re afraid of having no --- money? There''s irony...
On Tue, Aug 23, 2011 at 03:27:27PM +0100, Hugo Mills wrote:> On Tue, Aug 23, 2011 at 05:15:46PM +0300, Avi Kivity wrote: > > I''ve been using btrfs for a while as my /home (converted from ext4; > > encrypted lvm) when it died on me. Mounting it crashes immediately, > > here''s a log: > [...] > > [ 6.456117] Call Trace: > > [ 6.456117] [<ffffffffa005646e>] add_inode_ref+0x2e6/0x37c [btrfs] > > [ 6.456117] [<ffffffffa00493f6>] ? read_extent_buffer+0xc3/0xe3 [btrfs] > > [ 6.456117] [<ffffffffa0056e14>] replay_one_buffer+0x197/0x212 [btrfs] > > [ 6.456117] [<ffffffffa0054e94>] walk_down_log_tree+0x15a/0x2c1 [btrfs] > > [ 6.456117] [<ffffffffa005507a>] walk_log_tree+0x7f/0x19e [btrfs] > > [ 6.456117] [<ffffffff8123a8d9>] ? radix_tree_lookup+0xb/0xd > > [ 6.456117] [<ffffffffa0058148>] btrfs_recover_log_trees+0x28b/0x298 [btrfs] > > [ 6.456117] [<ffffffffa0056c7d>] ? replay_one_dir_item+0xbd/0xbd [btrfs] > > [ 6.456117] [<ffffffffa002a192>] open_ctree+0x10f1/0x13ff [btrfs] > [...] > > Tried btrfsck, immediate segfault. > > Yes, it does that,I''m afraid. (It also doesn''t fix anything). > > > Both kernel and btrfsprogs are stock Fedora 15. I still have the > > logical volume and would like to recover it. Its fairly easy to try > > out things in a virtual machine, so if you have a patch you want me to > > try out, I''m here. > > It looks like you''ve got a corrupt log tree. The quick and easy fix > for that is on the wiki in the problem FAQ page [1].... or use Josef''s fix first. :) H.> Could you give a bit more information about what happened in the > crash immediately prior to the FS being unmountable, and how your > storage is configured? > > Hugo. > > [1] https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_can.27t_mount_my_filesystem.2C_and_I_get_a_kernel_oops.21 >-- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You stay in the theatre because you''re afraid of having no --- money? There''s irony...
> This is fixed upstream, I''ve sent the patch to -stable so hopefully it > will show up in fedora soon, but in the meantime can you try Linus''s > tree and verify that it fixes it? Thanks,Thanks, it appears to be fixed (at least in a VM). Will try native soon. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Aug 23, 2011 at 5:27 PM, Hugo Mills <hugo@carfax.org.uk> wrote:> > Could you give a bit more information about what happened in the > crash immediately prior to the FS being unmountable,I was talking on the phone (HTC Desire running Android 2.2).> and how your > storage is configured?/dev/sda2 -> physical volume -> logical volume -> luks encryption -> btrfs -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 24, 2011 at 12:08 AM, Avi Kivity <avi.kivity@gmail.com> wrote:>> This is fixed upstream, I''ve sent the patch to -stable so hopefully it >> will show up in fedora soon, but in the meantime can you try Linus''s >> tree and verify that it fixes it? Thanks, > > Thanks, it appears to be fixed (at least in a VM). Will try native soon. >It''s back. 3.1-rc8: [ 24.431935] kernel BUG at fs/btrfs/tree-log.c:1690! [ 24.431935] invalid opcode: 0000 [#1] SMP [ 24.431935] CPU 0 [ 24.431935] Modules linked in: [ 24.431935] [ 24.431935] Pid: 1, comm: swapper Not tainted 3.1.0-rc8+ #4 Bochs Bochs [ 24.431935] RIP: 0010:[<ffffffff8127d8cc>] [<ffffffff8127d8cc>] replay_one_buffer+0x24c/0x330 [ 24.431935] RSP: 0018:ffff8800078d7810 EFLAGS: 00010282 [ 24.431935] RAX: 00000000fffffffb RBX: 0000000000000002 RCX: 00000000fffb921b [ 24.431935] RDX: ffffffffffffff24 RSI: 0000000000000001 RDI: 0000000000000286 [ 24.431935] RBP: ffff8800078d78b0 R08: ffff880006cabf18 R09: 9018000000000000 [ 24.431935] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000097 [ 24.431935] R13: ffff8800078d79b8 R14: ffff8800073755a0 R15: 000000000000000c [ 24.431935] FS: 0000000000000000(0000) GS:ffff880007c00000(0000) knlGS:0000000000000000 [ 24.431935] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 24.431935] CR2: 0000000000000000 CR3: 0000000001a05000 CR4: 00000000000006f0 [ 24.431935] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 24.431935] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 24.431935] Process swapper (pid: 1, threadinfo ffff8800078d6000, task ffff8800078d8000) [ 24.431935] Stack: [ 24.431935] ffff8800078d785e ffff880007372090 ffff8800078d78a0 ffffffff8126b38d [ 24.431935] ffff880007388000 ffff880006d0b000 ffff880007372120 ffff880006d0b400 [ 24.431935] 0000000000009d48 0005000000001000 060c000000000000 0500000000000000 [ 24.431935] Call Trace: [ 24.431935] [<ffffffff8126b38d>] ? alloc_extent_buffer+0x7d/0x420 [ 24.431935] [<ffffffff8127a90a>] walk_down_log_tree+0x1ea/0x3b0 [ 24.431935] [<ffffffff8127adcd>] walk_log_tree+0xbd/0x1d0 [ 24.431935] [<ffffffff8127eb21>] btrfs_recover_log_trees+0x211/0x300 [ 24.431935] [<ffffffff8127d680>] ? fixup_inode_link_counts+0x150/0x150 [ 24.431935] [<ffffffff8124b104>] open_ctree+0x13f4/0x17a0 [ 24.431935] [<ffffffff811c8eca>] ? disk_name+0xba/0xc0 [ 24.431935] [<ffffffff8122ba66>] btrfs_mount+0x426/0x5d0 [ 24.431935] [<ffffffff811656b0>] mount_fs+0x20/0xd0 [ 24.431935] [<ffffffff8117dc8a>] vfs_kern_mount+0x6a/0xc0 [ 24.431935] [<ffffffff8117f024>] do_kern_mount+0x54/0x110 [ 24.431935] [<ffffffff81180a2a>] do_mount+0x53a/0x840 [ 24.431935] [<ffffffff8111f1bb>] ? memdup_user+0x4b/0x90 [ 24.431935] [<ffffffff8111f25b>] ? strndup_user+0x5b/0x80 [ 24.431935] [<ffffffff81181118>] sys_mount+0x98/0xf0 [ 24.431935] [<ffffffff81b6bf0b>] mount_block_root+0xe4/0x28a [ 24.431935] [<ffffffff81171443>] ? sys_mknodat+0xc3/0x1f0 [ 24.431935] [<ffffffff81b6c237>] mount_root+0x53/0x57 [ 24.431935] [<ffffffff81b6c3a8>] prepare_namespace+0x16d/0x1a6 [ 24.431935] [<ffffffff81b6bd63>] kernel_init+0x153/0x158 [ 24.431935] [<ffffffff81061e67>] ? schedule_tail+0x27/0xb0 [ 24.431935] [<ffffffff81593074>] kernel_thread_helper+0x4/0x10 [ 24.431935] [<ffffffff81b6bc10>] ? start_kernel+0x3bb/0x3bb [ 24.431935] [<ffffffff81593070>] ? gs_change+0x13/0x13 [ 24.431935] Code: 8b 4d 90 48 8b 55 88 48 8b 75 98 41 89 d9 48 89 04 24 4d 89 f0 e8 e5 ea ff ff 83 f8 fe 0f 84 a2 fe ff ff 85 c0 0f 84 9a fe ff ff <0f> 0b 66 90 49 8b 7d 20 48 8b 55 90 4c 8d 4d ae 48 8b 75 98 41 [ 24.431935] RIP [<ffffffff8127d8cc>] replay_one_buffer+0x24c/0x330 [ 24.431935] RSP <ffff8800078d7810> [ 24.573567] ---[ end trace f1fff9aaced9257d ]--- [ 24.575888] Kernel panic - not syncing: Attempted to kill init! [ 24.578587] Pid: 1, comm: swapper Tainted: G D 3.1.0-rc8+ #4 [ 24.581490] Call Trace: [ 24.582643] [<ffffffff8157e978>] panic+0x91/0x1a7 [ 24.584839] [<ffffffff8106e000>] do_exit+0x760/0x830 [ 24.587148] [<ffffffff8106b75a>] ? kmsg_dump+0x4a/0xe0 [ 24.589520] [<ffffffff8158a48b>] oops_end+0xab/0xf0 [ 24.591794] [<ffffffff81016788>] die+0x58/0x90 [ 24.593879] [<ffffffff81589b94>] do_trap+0xc4/0x170 [ 24.596162] [<ffffffff81013e25>] do_invalid_op+0x95/0xb0 [ 24.598672] [<ffffffff8127d8cc>] ? replay_one_buffer+0x24c/0x330 [ 24.601534] [<ffffffff8117aa73>] ? iput+0x103/0x200 [ 24.603767] [<ffffffff8127c8a0>] ? add_inode_ref+0x500/0x520 [ 24.606333] [<ffffffff81592eeb>] invalid_op+0x1b/0x20 [ 24.608647] [<ffffffff8127d8cc>] ? replay_one_buffer+0x24c/0x330 [ 24.611366] [<ffffffff8126b38d>] ? alloc_extent_buffer+0x7d/0x420 [ 24.614119] [<ffffffff8127a90a>] walk_down_log_tree+0x1ea/0x3b0 [ 24.616829] [<ffffffff8127adcd>] walk_log_tree+0xbd/0x1d0 [ 24.619168] [<ffffffff8127eb21>] btrfs_recover_log_trees+0x211/0x300 [ 24.621825] [<ffffffff8127d680>] ? fixup_inode_link_counts+0x150/0x150 [ 24.624669] [<ffffffff8124b104>] open_ctree+0x13f4/0x17a0 [ 24.627186] [<ffffffff811c8eca>] ? disk_name+0xba/0xc0 [ 24.629735] [<ffffffff8122ba66>] btrfs_mount+0x426/0x5d0 [ 24.632180] [<ffffffff811656b0>] mount_fs+0x20/0xd0 [ 24.634475] [<ffffffff8117dc8a>] vfs_kern_mount+0x6a/0xc0 [ 24.636989] [<ffffffff8117f024>] do_kern_mount+0x54/0x110 [ 24.639528] [<ffffffff81180a2a>] do_mount+0x53a/0x840 [ 24.641886] [<ffffffff8111f1bb>] ? memdup_user+0x4b/0x90 [ 24.644360] [<ffffffff8111f25b>] ? strndup_user+0x5b/0x80 [ 24.646854] [<ffffffff81181118>] sys_mount+0x98/0xf0 [ 24.649200] [<ffffffff81b6bf0b>] mount_block_root+0xe4/0x28a [ 24.651793] [<ffffffff81171443>] ? sys_mknodat+0xc3/0x1f0 [ 24.654305] [<ffffffff81b6c237>] mount_root+0x53/0x57 [ 24.656610] [<ffffffff81b6c3a8>] prepare_namespace+0x16d/0x1a6 [ 24.659370] [<ffffffff81b6bd63>] kernel_init+0x153/0x158 [ 24.661878] [<ffffffff81061e67>] ? schedule_tail+0x27/0xb0 [ 24.664400] [<ffffffff81593074>] kernel_thread_helper+0x4/0x10 [ 24.667062] [<ffffffff81b6bc10>] ? start_kernel+0x3bb/0x3bb [ 24.669668] [<ffffffff81593070>] ? gs_change+0x13/0x13 Again, the machine died, and wouldn''t mount /home any more. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/30/2011 05:40 PM, Avi Kivity wrote:> On Wed, Aug 24, 2011 at 12:08 AM, Avi Kivity <avi.kivity@gmail.com> wrote: >>> This is fixed upstream, I''ve sent the patch to -stable so hopefully it >>> will show up in fedora soon, but in the meantime can you try Linus''s >>> tree and verify that it fixes it? Thanks, >> >> Thanks, it appears to be fixed (at least in a VM). Will try native soon. >> > > It''s back. 3.1-rc8: > >Thats -EIO, is there any messages before the bug? Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 3, 2011 at 4:34 PM, Josef Bacik <josef@redhat.com> wrote:> On 09/30/2011 05:40 PM, Avi Kivity wrote: >> On Wed, Aug 24, 2011 at 12:08 AM, Avi Kivity <avi.kivity@gmail.com> wrote: >>>> This is fixed upstream, I''ve sent the patch to -stable so hopefully it >>>> will show up in fedora soon, but in the meantime can you try Linus''s >>>> tree and verify that it fixes it? Thanks, >>> >>> Thanks, it appears to be fixed (at least in a VM). Will try native soon. >>> >> >> It''s back. 3.1-rc8: >> >> > > Thats -EIO, is there any messages before the bug? Thanks, >Not that I recall. I''ll check again when I''m near the poor thing again. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >> Thats -EIO, is there any messages before the bug? Thanks, >> > > Not that I recall. I''ll check again when I''m near the poor thing again. >Confirmed - that''s the first relevant message. As to -EIO, I dd''ed the entire volume and no errors were found. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 3, 2011 at 8:07 PM, Avi Kivity <avi.kivity@gmail.com> wrote:>>> >>> Thats -EIO, is there any messages before the bug? Thanks, >>> >> >> Not that I recall. I''ll check again when I''m near the poor thing again. >> > > Confirmed - that''s the first relevant message. > > As to -EIO, I dd''ed the entire volume and no errors were found. >btw, is there a new version of fsck.btrfs I can try? The one I have segfaults immediately. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 4, 2011 at 4:39 PM, Avi Kivity <avi.kivity@gmail.com> wrote:> On Mon, Oct 3, 2011 at 8:07 PM, Avi Kivity <avi.kivity@gmail.com> wrote: >>>> >>>> Thats -EIO, is there any messages before the bug? Thanks, >>>> >>> >>> Not that I recall. I''ll check again when I''m near the poor thing again. >>> >> >> Confirmed - that''s the first relevant message. >> >> As to -EIO, I dd''ed the entire volume and no errors were found. >> > > btw, is there a new version of fsck.btrfs I can try? The one I have > segfaults immediately. >Meanwhile, I used btrfs-zero-log and was able to remount. I have a snapshot of the dead filesystem, if someone wants to investigate. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/04/2011 03:40 PM, Avi Kivity wrote:> On Tue, Oct 4, 2011 at 4:39 PM, Avi Kivity <avi.kivity@gmail.com> wrote: >> On Mon, Oct 3, 2011 at 8:07 PM, Avi Kivity <avi.kivity@gmail.com> wrote: >>>>> >>>>> Thats -EIO, is there any messages before the bug? Thanks, >>>>> >>>> >>>> Not that I recall. I''ll check again when I''m near the poor thing again. >>>> >>> >>> Confirmed - that''s the first relevant message. >>> >>> As to -EIO, I dd''ed the entire volume and no errors were found. >>> >> >> btw, is there a new version of fsck.btrfs I can try? The one I have >> segfaults immediately. >> > > Meanwhile, I used btrfs-zero-log and was able to remount. I have a > snapshot of the dead filesystem, if someone wants to investigate.Yup I would love to investigate this, what kind of snapshot? Did you dd the drive or soemthing? Let me know where to pull it down. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Yup I would love to investigate this, what kind of snapshot?LVM snapshot.> Did you dd > the drive or soemthing? Let me know where to pull it down.Um, it''s my /home. It''s not leaving home. But if you have test kernels or btrfscks you want to throw at it, I''m happy to help. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/04/2011 03:50 PM, Avi Kivity wrote:>> Yup I would love to investigate this, what kind of snapshot? > > LVM snapshot. > >> Did you dd >> the drive or soemthing? Let me know where to pull it down. > > Um, it''s my /home. It''s not leaving home. But if you have test > kernels or btrfscks you want to throw at it, I''m happy to help.Hah well you can run btrfs-image -c <0-9> -t <number of threads> on your device it will create a image of the broken fs for me to look at and doesn''t copy any of the data and zero''s out any inline extents, the only thing I''ll potentially would be able to see is the file names. If that''s acceptable just upload it somewhere for me to pull down. If not I''ll put together a debug patch for you to try out. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 4, 2011 at 10:01 PM, Josef Bacik <josef@redhat.com> wrote:> On 10/04/2011 03:50 PM, Avi Kivity wrote: >>> Yup I would love to investigate this, what kind of snapshot? >> >> LVM snapshot. >> >>> Did you dd >>> the drive or soemthing? Let me know where to pull it down. >> >> Um, it''s my /home. It''s not leaving home. But if you have test >> kernels or btrfscks you want to throw at it, I''m happy to help. > > Hah well you can run btrfs-image -c <0-9> -t <number of threads> on your > device it will create a image of the broken fs for me to look at and > doesn''t copy any of the data and zero''s out any inline extents, the only > thing I''ll potentially would be able to see is the file names. If > that''s acceptable just upload it somewhere for me to pull down. If not > I''ll put together a debug patch for you to try out. Thanks, >Debug patches only, please. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html