Migration from the KQ Implementation

Aneurin Price aneurin.price at gmail.com
Thu May 5 09:45:25 EDT 2011

On Thu, May 5, 2011 at 02:08, Gordan Bobic <gordan.bobic at gmail.com> wrote:
> On 05/05/2011 02:05, Jason J. W. Williams wrote:
>>> Backups are of paramount importance, sure, but fsck is important, too,
>>> especially when a fsck pass might take 10 minutes vs. 2 days for
>>> restoring
>>> all the data from a backup (and the inevitable loss of anything since the
>>> last backup.
>> The question is what are expecting a ZFS fsck to do? Rollback to an
>> earlier consistent form of the filesystem? By default ZFS attempts
>> that already.
> No, that's just basic journal recovery and no fsck is needed. ext[3,4] does
> that, and there is still fsck for when that just isn't sufficient.
>> For situations where the hardware controller outright
>> lies to the OS about what it's doing and causes corruption, PSARC
>> 2009/479 (aka zpool recovery) attempts to clear out as many bad
>> transaction groups as it can to return the pool to a consistent
>> mountable state.
> You are still only talking about missing commits. I'm talking about
> different scenarios that aren't based on just the recent data getting
> trashed.

For example, I have a pool which contains one dataset which can't be deleted.

So far I've only tried with zfs-fuse since I prefer to wait for native
ZFS to have a few more months' testing before trying it. Maybe
(hopefully) the newest versions of ZFS will be able to deal with the
problem, but zfs-fuse crashes when I try to delete that dataset or its
contents. This corruption happened at some unknown point before I
discovered it - *far* too late to simply figure out when it was
definitely still good and roll back. In fact, if I *try* deleting that
data, I then have to roll back the pool to before the attempt as ZFS
crashes, then tries to complete the delete operation on import, and
dies again. It sounds like that rollback is easier nowadays, but when
I first came across it my only option was to zero bits of the on-disk
data structures directly to coax ZFS into giving me a working pool.

Needless to say, the pool scrubs just fine because none of the data is
damaged; it's just that there's some FS metadata which is incorrect. A
real fsck tool would be able to fix this, but ZFS is designed by
idealists who stubbornly refuse to accept reality.

FWIW, I think ZFS is a very cool toy, and a usable stopgap until BTRFS
is complete, but not a sane choice for real use because its designers
care more about being able to point out that something is wrong than
they do about pragmatic concerns like actually fixing it - or even
trying to make the best possible attempt.


More information about the zfs-discuss mailing list