On Tue, Jan 17, 2012 at 03:07:16PM +0000, David Summers wrote: > On 18/08/11 21:50, Chris Mason wrote: > >Excerpts from Yalonda Gishtaka's message of 2011-08-17 21:09:37 -0400: > >>Chris Mason<chris.mason<at> oracle.com> writes: > >> > >>> > >>>Aside from making sure the kernel code is stable, btrfsck is all I'm > >>>working on right now. I do expect a release in the next two weeks that > >>>can recover your data (and many others). > >>> > >>>Thanks, > >>>Chris > >>>-- > >> > >> > >>Chris, > >> > >>We're all on the edge of our seats. Can you provide an updated ETA on the > >>release of the first functional btrfsck tool? No pressure or anything ;) > > > >Hi everyone, > > > >I've been working non-stop on this. Currently fsck has four parts: > > > >1) mount -o recovery mode. I've posted smaller forms of these patches > >in the past that bypass log tree replay. The new versions have code to > >create stub roots for trees that can't be read (like the extent > >allocation tree) and will allow the mount to proceed. > > > >2) fsck that scans for older roots. This takes advantage of older > >copies of metadata to look for consistent tree roots on disk. The > >downside is that it is currently very slow. I'm trying to speed it up > >by limiting the search to only the metadata block groups and a few other > >tricks. > > > >3) fsck that fixes the extent allocation tree and the chunk tree. This > >is where I've been spending most of my time. The problem is that it > >tends to recover some filesystems and badly break others. While I'm > >fixing up the corner cases that work poorly, I'm adding an undo log to > >the fsck code so that you can get the FS back into its original state if > >you don't like the result of the fsck. > > > >4) The rest of the corruptions can be dealt with fairly well from the > >kernel. I have a series of patches to make the extent allocation tree > >less strict about reference counts and other rules, basically allowing > >the FS to limp along instead of crash. > > > >These four things together are basically my minimal set of features > >required for fedora and our own internal projects at Oracle to start > >treating us as production filesystem. > > > >There are always bugs to fix, and I have #1 and #2 mostly ready. I had > >hoped to get #1 out the door before I left on vacation and I still might > >post it tonight. > > > > Just checking my reading on where we are is correct. > > 1&2 have been done? > > Whats the progress on 3&4 - is Chris the only one working on these, > or are others active?
People have already started picking up #4, fujitsu had some patches in this direction that we'll keep developing with. I stepped back to add some directory metadata fixups as well to the basic fsck tool. I had thought I could easily do it all from the kernel, but sometimes the userland side really is easier. -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
