On Tue, Jan 17, 2012 at 03:07:16PM +0000, David Summers wrote:

On 18/08/11 21:50, Chris Mason wrote:

quoted

Excerpts from Yalonda Gishtaka's message of 2011-08-17 21:09:37 -0400:

quoted

Chris Mason<chris.mason<at>  oracle.com>  writes:

quoted

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