Why ZFS still needs an equivalent of fsck

April 8, 2013

One of the things that is more or less a FAQ in ZFS circles is why ZFS doesn't need an equivalent of fsck and why people asking for it are wrong. Unfortunately, the ZFS people making that argument are, in the end, wrong because they have not fully understood the purpose of fsck.

Fsck has two meta-purposes (as opposed to its direct purposes). The obvious one is checking and repairing filesystem consistency when the filesystem gets itself into an inconsistent state due to sudden power failure or the like; this is the traditional Unix use of fsck. As lots of people will tell you, ZFS doesn't need an external tool to do this because it is all built in. ZFS even does traditional fsck one better in that it can safely do the equivalent of periodic precautionary fscks in normal operation, by scrubbing the pool.

(Our ZFS pools are scrubbed regularly and thus are far more solidly intact than traditional filesystems are.)

The less obvious meta-purpose of fsck is putting as much of your filesystem as possible back together when things explode badly. ZFS manifestly needs something to do this job because there are any number of situations today where ZFS will simply throw up its hands and say 'it sucks to be you, I'm done here'. This is not really solvable in ZFS either, because you really can't put this sort of serious recovery mechanisms into the normal kernel filesystem layer; in many cases they would involve going to extreme lengths and violating the guarantees normally provided by ZFS (cf). This means external user-level tools.

(zdb does not qualify here because it is too low-level a tool. The goal of fsck-level tools for disaster recovery is to give you a relatively hands-off experience and zdb is anything but hands-off.)

PS: despite this logic I don't expect ZFS to ever get such a tool. Writing it would be a lot of work, probably would not be popular with ZFS people, and telling people 'restore from your backups' is much simpler and more popular. And if they don't have (current) backups, well, that's not ZFS's problem is it.

(As usual that is the wrong answer.)


Comments on this page:

From 220.233.22.202 at 2013-04-08 06:59:34:

Depending on what kind of failure you have, more tools for importing an ostensibly broken pool exist than are immediately visible. Though not mentioned in the manual pages, the source for zpool(1M) at least contains a block comment mentioning some of the rollback/rewind import flags:

http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/zpool/zpool_main.c#1729

I think it's unfair to suggest that the "ZFS people" are averse to fixing problems that people have. The on-disk structures are reasonably intricate. Having been in the ZFS code myself, I suspect that any recovery process for a deeply damaged pool is likely going to be a heuristic, human-assisted effort.

I would certainly expect that the community would welcome the addition of text to the zpool(1M) manual page to document the missing flags. If there's a class of problem for which automated recovery is algorithmic and well-understood, but somehow not a candidate for just improving the filesystem code itself, then I'm sure we would consider a fsck-equivalent as well.

-- Joshua M. Clulow

From 38.104.194.102 at 2013-04-08 11:57:07:

Any situation in which the "things explode badly" and the filesystem is not recoverable (not a result of firmware or hardware error) represents a serious filesystem bug. You say there are "a number of situations today" where this happens -- do you have any references for that claim?

-- Dave Pacheco

Written on 08 April 2013.
« The apparent source of my Firefox memory bloat problems
Fedora 18's TexLive packaging failure »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Mon Apr 8 01:30:08 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.