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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
