I''m getting a rather nasty BUG when I try to mount this filesystem, _including_ when I specify -o ro. I''m unsure what caused it, but the problem manifested after my computer hardlocked while reading my RSS feeds, complete with flashing lights. After I rebooted it, the screen filled with panic messages when the initramfs tried to mount it RO to pivot into. I am running 2.6.33-rc6. The BUG message is as follows: [ 6169.574592] ------------[ cut here ]------------ [ 6169.575423] Kernel BUG at ffffffff81244cf8 [verbose debug info unavailable] [ 6169.575423] invalid opcode: 0000 [#1] PREEMPT SMP [ 6169.575423] last sysfs file: /sys/devices/pci0000:00/0000:00:1c.3/0000:06:00.0/firmware/0000:06:00.0/loading [ 6169.575423] CPU 0 [ 6169.593813] Pid: 3457, comm: mount Not tainted 2.6.33-rc6-zen1 #3 MS-1651/GX620 [ 6169.594013] RIP: 0010:[<ffffffff81244cf8>] [<ffffffff81244cf8>] add_inode_ref+0x69/0x423 [ 6169.594013] RSP: 0018:ffff88013a587888 EFLAGS: 00010246 [ 6169.594013] RAX: 0000000000000000 RBX: ffff8800a98dfe10 RCX: ffff880137d7b720 [ 6169.594013] RDX: ffff88013a5877e8 RSI: ffff8800a153e000 RDI: ffff88013a587800 [ 6169.594013] RBP: ffff88013a587948 R08: ffff880005a127e0 R09: ffff880137d72530 [ 6169.594013] R10: ffff88013a587758 R11: dead000000200200 R12: ffff8800a153e000 [ 6169.594013] R13: ffff8800268d3cb0 R14: 0000000000000000 R15: ffff88013a5879a8 [ 6169.594013] FS: 00007f517839e740(0000) GS:ffff880005a00000(0000) knlGS:0000000000000000 [ 6169.594013] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 6169.594013] CR2: 00007fd3edf7ee40 CR3: 0000000123136000 CR4: 00000000000006f0 [ 6169.594013] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 6169.649381] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 6169.649381] Process mount (pid: 3457, threadinfo ffff88013a586000, task ffff880136a32e00) [ 6169.649381] Stack: [ 6169.649381] ffff88013a587900 ffffffff00000004 ffff8800a153f800 00000000000000ac [ 6169.649381] <0> 0000000000000065 00000002a9837630 0000000000000097 ffffffff816acf65 [ 6169.649381] <0> ffff88013a5878d8 ffffffff81233d0e ffff88013a587948 ffffffff8122a4e2 [ 6169.649381] Call Trace: [ 6169.649381] [<ffffffff816acf65>] ? sub_preempt_count+0x9/0x83 [ 6169.649381] [<ffffffff81233d0e>] ? unmap_extent_buffer+0x13/0x2e [ 6169.649381] [<ffffffff8122a4e2>] ? btrfs_item_size+0xbb/0xcb [ 6169.649381] [<ffffffff81245e54>] replay_one_buffer+0x27e/0x310 [ 6169.649381] [<ffffffff81243138>] walk_down_log_tree+0x277/0x5fd [ 6169.649381] [<ffffffff8124359d>] walk_log_tree+0xdf/0x250 [ 6169.649381] [<ffffffff816a9ac9>] ? _raw_spin_unlock+0x15/0x30 [ 6169.649381] [<ffffffff81244714>] btrfs_recover_log_trees+0x1be/0x2d6 [ 6169.649381] [<ffffffff81245bd6>] ? replay_one_buffer+0x0/0x310 [ 6169.649381] [<ffffffff81216ccd>] ? btree_read_extent_buffer_pages+0x71/0xaf [ 6169.649381] [<ffffffff8121ac4e>] open_ctree+0x12d2/0x154a [ 6169.649381] [<ffffffff812dbc0b>] ? vsnprintf+0x1d8/0x44b [ 6169.649381] [<ffffffff811fda01>] btrfs_get_sb+0x1d0/0x3ec [ 6169.649381] [<ffffffff81123806>] vfs_kern_mount+0xa9/0x168 [ 6169.649381] [<ffffffff8112392d>] do_kern_mount+0x4d/0xed [ 6169.649381] [<ffffffff8113a19b>] do_mount+0x786/0x7fd [ 6169.649381] [<ffffffff810eed34>] ? strndup_user+0x5d/0x85 [ 6169.649381] [<ffffffff8113a29a>] sys_mount+0x88/0xc2 [ 6169.649381] [<ffffffff81009c52>] system_call_fastpath+0x16/0x1b [ 6169.649381] Code: 89 e7 e8 05 eb ff ff 49 89 c5 b8 fe ff ff ff 4d 85 ed 0f 84 bb 03 00 00 49 8b 37 4c 89 e7 e8 e9 ea ff ff 49 89 c6 48 85 c0 75 04 <0f> 0b eb fe 48 63 85 6c ff ff ff 48 8b 7d b0 48 6b c0 19 48 83 [ 6169.649381] RIP [<ffffffff81244cf8>] add_inode_ref+0x69/0x423 [ 6169.649381] RSP <ffff88013a587888> [ 6169.867976] ---[ end trace 4b4c67dcecd13d7d ]--- I ran btrfsck on it, which produced this output: root 5 inode 1525410 errors 400 root 5 inode 5364659 errors 2 root 5 inode 5364663 errors 2 root 5 inode 5364668 errors 2 root 5 inode 5364677 errors 2 root 5 inode 6123691 errors 400 root 5 inode 6239775 errors 2 root 5 inode 6239779 errors 2 root 5 inode 6239789 errors 2 root 5 inode 6239971 errors 2 root 5 inode 6269030 errors 2 root 5 inode 6269034 errors 2 root 5 inode 6269667 errors 2 root 5 inode 6270025 errors 2 root 5 inode 6423082 errors 400 root 5 inode 6424288 errors 2 root 5 inode 6424328 errors 2 root 5 inode 6424506 errors 2 root 5 inode 6424510 errors 2 root 5 inode 7314036 errors 400 root 5 inode 7538573 errors 400 root 5 inode 7541407 errors 400 root 5 inode 7541533 errors 400 root 5 inode 7954626 errors 400 root 5 inode 7955659 errors 2 root 5 inode 7955723 errors 2 root 5 inode 7955727 errors 2 root 5 inode 7957158 errors 2 root 5 inode 8076299 errors 2 root 5 inode 8138735 errors 400 root 5 inode 8346718 errors 400 root 5 inode 8378669 errors 400 root 5 inode 8504794 errors 400 root 5 inode 8628757 errors 400 root 5 inode 8628952 errors 2 root 5 inode 8628966 errors 2 root 5 inode 8628970 errors 2 root 5 inode 8629003 errors 2 root 5 inode 8633819 errors 2 root 5 inode 8693549 errors 400 root 5 inode 9014871 errors 2 root 5 inode 9014938 errors 2 root 5 inode 9014942 errors 2 root 5 inode 9014946 errors 2 found 449101881344 bytes used err is 1 total csum bytes: 433187792 total tree bytes: 5517582336 total fs tree bytes: 4585160704 btree space waste bytes: 1419008115 file data blocks allocated: 1040877457408 referenced 439746732032 Btrfs v0.19-4-gab8fb4c Is there any way to salvage this filesystem? -- 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 Fri, Feb 12, 2010 at 1:04 PM, Alex Elsayed <eternaleye@gmail.com> wrote:> I''m getting a rather nasty BUG when I try to mount this filesystem, > _including_ when I specify -o ro. I''m unsure what caused it, but the problem > manifested after my computer hardlocked while reading my RSS feeds, complete > with flashing lights. After I rebooted it, the screen filled with panic > messages when the initramfs tried to mount it RO to pivot into. I am running > 2.6.33-rc6. The BUG message is as follows:Is this the bug you mentioned on IRC that you fixed somehow? If so please post the steps you performed. -- 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
Mike Fedyk <mfedyk <at> mikefedyk.com> writes:> > On Fri, Feb 12, 2010 at 1:04 PM, Alex Elsayed <eternaleye <at> gmail.com>wrote:> > I''m getting a rather nasty BUG when I try to mount this filesystem, > > _including_ when I specify -o ro. I''m unsure what caused it, but the problem > > manifested after my computer hardlocked while reading my RSS feeds, complete > > with flashing lights. After I rebooted it, the screen filled with panic > > messages when the initramfs tried to mount it RO to pivot into. I am running > > 2.6.33-rc6. The BUG message is as follows: > > Is this the bug you mentioned on IRC that you fixed somehow? > > If so please post the steps you performed.No, that bug was on a different hard drive and was due to bad blocks. That instance was converted from ext4, while this is a new mkfs. The steps necessary to reproduce the BUG are simple - mount -o ro /dev/Arkadios/Root $mountpoint. I''m currently running from my initramfs, with that old system mounted ro and bound to /usr (since that problem only occurred when writing to the disk, it makes a passable recovery environment). -- 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
Alex Elsayed <eternaleye <at> gmail.com> writes:> > Mike Fedyk <mfedyk <at> mikefedyk.com> writes: > > > > > On Fri, Feb 12, 2010 at 1:04 PM, Alex Elsayed <eternaleye <at> gmail.com> > wrote: > > > I''m getting a rather nasty BUG when I try to mount this filesystem, > > > _including_ when I specify -o ro. I''m unsure what caused it, but theproblem> > > manifested after my computer hardlocked while reading my RSS feeds,complete> > > with flashing lights. After I rebooted it, the screen filled with panic > > > messages when the initramfs tried to mount it RO to pivot into. I amrunning> > > 2.6.33-rc6. The BUG message is as follows: > > > > Is this the bug you mentioned on IRC that you fixed somehow? > > > > If so please post the steps you performed. > > No, that bug was on a different hard drive and was due to bad blocks. That > instance was converted from ext4, while this is a new mkfs. The stepsnecessary> to reproduce the BUG are simple - mount -o ro /dev/Arkadios/Root $mountpoint. > I''m currently running from my initramfs, with that old system mounted ro and > bound to /usr (since that problem only occurred when writing to the disk, it > makes a passable recovery environment).I have run btrfs-image on the partition, but due to it spanning the better part of 500GB (80% full), it''s 1.1GB. I therefore can''t attach it, but if there''s somewhere I can FTP or otherwise upload it to so it can be examined, please let me know. -- 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 Fri, Feb 12, 2010 at 09:04:39PM +0000, Alex Elsayed wrote:> I''m getting a rather nasty BUG when I try to mount this filesystem, > _including_ when I specify -o ro. I''m unsure what caused it, but the problem > manifested after my computer hardlocked while reading my RSS feeds, complete > with flashing lights. After I rebooted it, the screen filled with panic > messages when the initramfs tried to mount it RO to pivot into. I am running > 2.6.33-rc6. The BUG message is as follows:The good news is this looks like a bug that Yan Zheng fixed. 2.6.33-rc7 or later should mount without problems. If you''re having trouble getting that image onto that box, I''ll get a usb boot image up with it running for you. -chris -- 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
Chris Mason <chris.mason <at> oracle.com> writes:> > On Fri, Feb 12, 2010 at 09:04:39PM +0000, Alex Elsayed wrote: > > I''m getting a rather nasty BUG when I try to mount this filesystem, > > _including_ when I specify -o ro. I''m unsure what caused it, but the problem > > manifested after my computer hardlocked while reading my RSS feeds, complete > > with flashing lights. After I rebooted it, the screen filled with panic > > messages when the initramfs tried to mount it RO to pivot into. I am running > > 2.6.33-rc6. The BUG message is as follows: > > The good news is this looks like a bug that Yan Zheng fixed. 2.6.33-rc7 > or later should mount without problems. If you''re having trouble > getting that image onto that box, I''ll get a usb boot image up with it > running for you. > > -chrisNo such luck. -rc8 still BUGs. Trace below: [ 1340.258885] ------------[ cut here ]------------ [ 1340.258895] kernel BUG at fs/btrfs/tree-log.c:809! [ 1340.258901] invalid opcode: 0000 [#1] PREEMPT SMP [ 1340.258910] last sysfs file: /sys/fs/ecryptfs/version [ 1340.258915] CPU 0 [ 1340.258924] Pid: 2795, comm: mount Not tainted 2.6.33-rc8-zen1 #1 MS- 1651/GX620 [ 1340.258930] RIP: 0010:[<ffffffff8124662c>] [<ffffffff8124662c>] add_inode_ref+0x69/0x423 [ 1340.258947] RSP: 0018:ffff880037ae7888 EFLAGS: 00010246 [ 1340.258952] RAX: 0000000000000000 RBX: ffff8800375df090 RCX: ffff880104b41f80 [ 1340.258958] RDX: ffff880037ae77e8 RSI: ffff8800bd5b7800 RDI: ffff88013b6c3800 [ 1340.258964] RBP: ffff880037ae7948 R08: ffff880005a12800 R09: ffff88010bebe0d0 [ 1340.258970] R10: ffff880037ae7758 R11: 0000000000000000 R12: ffff8800bd5b7800 [ 1340.258976] R13: ffff880104b41940 R14: 0000000000000000 R15: ffff880037ae79a8 [ 1340.258983] FS: 00007f8363b58740(0000) GS:ffff880005a00000(0000) knlGS:0000000000000000 [ 1340.258989] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1340.258995] CR2: 00007fa762002000 CR3: 0000000037af2000 CR4: 00000000000006f0 [ 1340.259001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1340.259007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 1340.259013] Process mount (pid: 2795, threadinfo ffff880037ae6000, task ffff880037971700) [ 1340.259018] Stack: [ 1340.259022] ffff880037ae7900 ffffffff00000004 ffff8800bd5b4800 00000000000000ac [ 1340.259032] <0> 0000000000000065 00000002375995a0 0000000000000097 ffffffff81728165 [ 1340.259042] <0> ffff880037ae78d8 ffffffff81235642 ffff880037ae7948 ffffffff8122be16 [ 1340.259054] Call Trace: [ 1340.259066] [<ffffffff81728165>] ? sub_preempt_count+0x9/0x83 [ 1340.259074] [<ffffffff81235642>] ? unmap_extent_buffer+0x13/0x2e [ 1340.259083] [<ffffffff8122be16>] ? btrfs_item_size+0xbb/0xcb [ 1340.259092] [<ffffffff81247788>] replay_one_buffer+0x27e/0x310 [ 1340.259102] [<ffffffff81244a6c>] walk_down_log_tree+0x277/0x5fd [ 1340.259111] [<ffffffff81244ed1>] walk_log_tree+0xdf/0x250 [ 1340.259119] [<ffffffff81724cf1>] ? _raw_spin_unlock+0x15/0x30 [ 1340.259128] [<ffffffff81246048>] btrfs_recover_log_trees+0x1be/0x2d6 [ 1340.259137] [<ffffffff8124750a>] ? replay_one_buffer+0x0/0x310 [ 1340.259146] [<ffffffff812185fd>] ? btree_read_extent_buffer_pages+0x71/0xaf [ 1340.259156] [<ffffffff8121c568>] open_ctree+0x12bc/0x15c9 [ 1340.259165] [<ffffffff812dda73>] ? vsnprintf+0x1d8/0x44b [ 1340.259177] [<ffffffff811ff32d>] btrfs_get_sb+0x1d0/0x3ec [ 1340.259188] [<ffffffff81124f46>] vfs_kern_mount+0xa9/0x168 [ 1340.259196] [<ffffffff8112506d>] do_kern_mount+0x4d/0xed [ 1340.259206] [<ffffffff8113b917>] do_mount+0x786/0x7fd [ 1340.259215] [<ffffffff810effe4>] ? strndup_user+0x5d/0x85 [ 1340.259223] [<ffffffff8113ba16>] sys_mount+0x88/0xc2 [ 1340.259233] [<ffffffff81009c52>] system_call_fastpath+0x16/0x1b [ 1340.259238] Code: 89 e7 e8 05 eb ff ff 49 89 c5 b8 fe ff ff ff 4d 85 ed 0f 84 bb 03 00 00 49 8b 37 4c 89 e7 e8 e9 ea ff ff 49 89 c6 48 85 c0 75 04 <0f> 0b eb fe 48 63 85 6c ff ff ff 48 8b 7d b0 48 6b c0 19 48 83 [ 1340.259327] RIP [<ffffffff8124662c>] add_inode_ref+0x69/0x423 [ 1340.259337] RSP <ffff880037ae7888> [ 1340.259377] ---[ end trace 81037f7cb67410e7 ]--- -- 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 Thu, Feb 18, 2010 at 12:35:18AM +0000, Alex Elsayed wrote:> Chris Mason <chris.mason <at> oracle.com> writes: > > > > > On Fri, Feb 12, 2010 at 09:04:39PM +0000, Alex Elsayed wrote: > > > I''m getting a rather nasty BUG when I try to mount this filesystem, > > > _including_ when I specify -o ro. I''m unsure what caused it, but the problem > > > manifested after my computer hardlocked while reading my RSS feeds, complete > > > with flashing lights. After I rebooted it, the screen filled with panic > > > messages when the initramfs tried to mount it RO to pivot into. I am running > > > 2.6.33-rc6. The BUG message is as follows: > > > > The good news is this looks like a bug that Yan Zheng fixed. 2.6.33-rc7 > > or later should mount without problems. If you''re having trouble > > getting that image onto that box, I''ll get a usb boot image up with it > > running for you. > > > > -chris > > No such luck. -rc8 still BUGs. Trace below:Ugh ok. The first thing I''d like to do is give you a patch to completely disable the tree log replay and give you the chance to backup critical data. Do you already have a backup of the critical things on this drive? The problem you''re hitting is that tree-logging code is trying to replay an fsync of a file, but it can''t find the file to replay. This could be a small and localized corruption or it could be a larger problem. We''ll have to fix things one at a time to figure it out. The easiest way to move forward would be to save a complete copy of the FS with dd, but that''s probably not very easy given the size. -chris -- 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
Chris Mason <chris.mason <at> oracle.com> writes:> > Ugh ok. The first thing I''d like to do is give you a patch to > completely disable the tree log replay and give you the chance to backup > critical data. > > Do you already have a backup of the critical things on this drive? The > problem you''re hitting is that tree-logging code is trying to replay an > fsync of a file, but it can''t find the file to replay. This could be a > small and localized corruption or it could be a larger problem. We''ll > have to fix things one at a time to figure it out. > > The easiest way to move forward would be to save a complete copy of the > FS with dd, but that''s probably not very easy given the size. > > -chrisWell, I ran badblocks on the drive, and it was happily silent, so that''s a good sign. I alo attached btrfsck output upthread, which says that there are 44 inodes with errors. Unfortunately, I don''t really have a drive big enough to back up to. I may be able to borrow one from a friend, though. -- 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 Thu, Feb 18, 2010 at 05:38:22PM +0000, Alex Elsayed wrote:> Chris Mason <chris.mason <at> oracle.com> writes: > > > > > Ugh ok. The first thing I''d like to do is give you a patch to > > completely disable the tree log replay and give you the chance to backup > > critical data. > > > > Do you already have a backup of the critical things on this drive? The > > problem you''re hitting is that tree-logging code is trying to replay an > > fsync of a file, but it can''t find the file to replay. This could be a > > small and localized corruption or it could be a larger problem. We''ll > > have to fix things one at a time to figure it out. > > > > The easiest way to move forward would be to save a complete copy of the > > FS with dd, but that''s probably not very easy given the size. > > > > -chris > > Well, I ran badblocks on the drive, and it was happily silent, so that''s a good > sign. I alo attached btrfsck output upthread, which says that there are 44 > inodes with errors. Unfortunately, I don''t really have a drive big enough to > back up to. I may be able to borrow one from a friend, though.I think the btrfsck output is missing. It sounds like we''ll survive if we just skip this part of the log replay. I''ll cook a patch based on the btrfsck output. -chris -- 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
Chris Mason <chris.mason <at> oracle.com> writes:> I think the btrfsck output is missing. It sounds like we''ll survive if > we just skip this part of the log replay. I''ll cook a patch based on > the btrfsck output.It was inline in my first message, immediately after the BUG trace. -- 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
Alex Elsayed <eternaleye <at> gmail.com> writes:> > Chris Mason <chris.mason <at> oracle.com> writes: > > I think the btrfsck output is missing. It sounds like we''ll survive if > > we just skip this part of the log replay. I''ll cook a patch based on > > the btrfsck output. > > It was inline in my first message, immediately after the BUG trace.Any update? Including btrfsck output here, in case it got lost: Arkadios ~ # btrfsck /dev/Arkadios/Root root 5 inode 1525410 errors 400 root 5 inode 5364659 errors 2 root 5 inode 5364663 errors 2 root 5 inode 5364668 errors 2 root 5 inode 5364677 errors 2 root 5 inode 6123691 errors 400 root 5 inode 6239775 errors 2 root 5 inode 6239779 errors 2 root 5 inode 6239789 errors 2 root 5 inode 6239971 errors 2 root 5 inode 6269030 errors 2 root 5 inode 6269034 errors 2 root 5 inode 6269667 errors 2 root 5 inode 6270025 errors 2 root 5 inode 6423082 errors 400 root 5 inode 6424288 errors 2 root 5 inode 6424328 errors 2 root 5 inode 6424506 errors 2 root 5 inode 6424510 errors 2 root 5 inode 7314036 errors 400 root 5 inode 7538573 errors 400 root 5 inode 7541407 errors 400 root 5 inode 7541533 errors 400 root 5 inode 7954626 errors 400 root 5 inode 7955659 errors 2 root 5 inode 7955723 errors 2 root 5 inode 7955727 errors 2 root 5 inode 7957158 errors 2 root 5 inode 8076299 errors 2 root 5 inode 8138735 errors 400 root 5 inode 8346718 errors 400 root 5 inode 8378669 errors 400 root 5 inode 8504794 errors 400 root 5 inode 8628757 errors 400 root 5 inode 8628952 errors 2 root 5 inode 8628966 errors 2 root 5 inode 8628970 errors 2 root 5 inode 8629003 errors 2 root 5 inode 8633819 errors 2 root 5 inode 8693549 errors 400 root 5 inode 9014871 errors 2 root 5 inode 9014938 errors 2 root 5 inode 9014942 errors 2 root 5 inode 9014946 errors 2 found 449101881344 bytes used err is 1 total csum bytes: 433187792 total tree bytes: 5517582336 total fs tree bytes: 4585156608 btree space waste bytes: 1419008115 file data blocks allocated: 1040877457408 referenced 439746732032 Btrfs Btrfs v0.19 -- 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, Feb 23, 2010 at 08:30:56AM +0000, Alex Elsayed wrote:> Alex Elsayed <eternaleye <at> gmail.com> writes: > > > > > Chris Mason <chris.mason <at> oracle.com> writes: > > > I think the btrfsck output is missing. It sounds like we''ll survive if > > > we just skip this part of the log replay. I''ll cook a patch based on > > > the btrfsck output. > > > > It was inline in my first message, immediately after the BUG trace. > > Any update? Including btrfsck output here, in case it got lost:Sorry for the delay. With this patch, you''ll have a consistent filesystem but any fsyncs that were done before your last crash are not going to be there after the mount. The tree logging code should be made more tolerant of this problem, but that is a larger change that will take longer to get right. And you want to mount this FS and get to your data. With this patch, mount -o danger_del_log_tree /dev/xxx Just let me know how things are working afterwards: diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index 2aa8ec6..1a532a5 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -1162,6 +1162,7 @@ struct btrfs_root { #define BTRFS_MOUNT_NOSSD (1 << 9) #define BTRFS_MOUNT_DISCARD (1 << 10) #define BTRFS_MOUNT_FORCE_COMPRESS (1 << 11) +#define BTRFS_MOUNT_DELLOGTREE (1 << 12) #define btrfs_clear_opt(o, opt) ((o) &= ~BTRFS_MOUNT_##opt) #define btrfs_set_opt(o, opt) ((o) |= BTRFS_MOUNT_##opt) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 2b59201..aa2aa59 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -1955,6 +1955,13 @@ struct btrfs_root *open_ctree(struct super_block *sb, err = -EIO; goto fail_trans_kthread; } + + if (btrfs_test_opt(tree_root, DELLOGTREE)) { + printk(KERN_WARNING "Btrfs deleting log tree"); + btrfs_set_super_log_root(disk_super, 0); + goto postrecover; + } + blocksize btrfs_level_size(tree_root, btrfs_super_log_root_level(disk_super)); @@ -1968,15 +1975,16 @@ struct btrfs_root *open_ctree(struct super_block *sb, log_tree_root->node = read_tree_block(tree_root, bytenr, blocksize, generation + 1); + ret = btrfs_recover_log_trees(log_tree_root); BUG_ON(ret); +postrecover: if (sb->s_flags & MS_RDONLY) { ret = btrfs_commit_super(tree_root); BUG_ON(ret); } } - ret = btrfs_find_orphan_roots(tree_root); BUG_ON(ret); diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 8a1ea6e..6132721 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -67,7 +67,7 @@ enum { Opt_max_extent, Opt_max_inline, Opt_alloc_start, Opt_nobarrier, Opt_ssd, Opt_nossd, Opt_ssd_spread, Opt_thread_pool, Opt_noacl, Opt_compress, Opt_compress_force, Opt_notreelog, Opt_ratio, - Opt_flushoncommit, + Opt_flushoncommit, Opt_danger_del_log_tree, Opt_discard, Opt_err, }; @@ -92,6 +92,7 @@ static match_table_t tokens = { {Opt_flushoncommit, "flushoncommit"}, {Opt_ratio, "metadata_ratio=%d"}, {Opt_discard, "discard"}, + {Opt_danger_del_log_tree, "danger_del_log_tree"}, {Opt_err, NULL}, }; @@ -270,6 +271,9 @@ int btrfs_parse_options(struct btrfs_root *root, char *options) case Opt_discard: btrfs_set_opt(info->mount_opt, DISCARD); break; + case Opt_danger_del_log_tree: + btrfs_set_opt(info->mount_opt, DELLOGTREE); + break; case Opt_err: printk(KERN_INFO "btrfs: unrecognized mount option " "''%s''\n", p); -- 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