Re: Honest timeline for btrfsck

[Chris Mason <chris.mason@oracle.com>]

Excerpts from Asdo's message of 2011-10-07 15:10:33 -0400:
> On 10/07/11 04:25, Chester wrote:
> > The problem with this is that people naturally look for a fsck tool
> > when something bad goes wrong. Something as important as a fsck
> > utility shouldn't be released (unofficially or officially) half baked.
> > It can irreparably destroy a filesystem which could've otherwise been
> > repaired with a fully functional fsck.
> >
> > I think Chris is trying to prevent that from happening.
> 
> What I would like to know instead, is WHY we need an btrfsck when ZFS 
> does not. Zfs also has this kind of problems especially on power 
> failures, but you can always mount by rolling back to a previous 
> uberblock, showing an earlier view of the filesystem, which would be 
> consistent.
> 
> It wasn't always like this with ZFS, but this "feature" has been added 
> after ther numerous requests of users who lost their complete 
> filesystems after a power failure or similar events. And there was no 
> zfsck (there still isn't, and it's apparently not needed).

One of my patches here adds a circular ring of past roots for a similar
feature.  The problem is that blocks get reused after a commit, so we
have to either slow that down (making enospc even more complex) or we'd
have to just use the past super and hope.

It gets even worse because things past supers aren't always enough.  The
drive can just plain corrupt an important block, or write-back cache
problems can make corruptions that last much longer than the last 5 or
10 commits.  Bad things do happen to good data, so you just plain need a
real fsck.

-chris