Linked by Pobrecito Hablador on Mon 2nd Nov 2009 21:19 UTC
Sun Solaris, OpenSolaris One of the advantages of ZFS is that it doesn't need a fsck. Replication, self-healing and scrubbing are a much better alternative. After a few years of ZFS life, can we say it was the correct decision? The reports in the mailing list are a good indicator of what happens in the real world, and it appears that once again, reality beats theory. The author of the article analyzes the implications of not having a fsck tool and tries to explain why he thinks Sun will add one at some point.
Thread beginning with comment 392347
To read all comments associated with this story, please click here.
ZFS doesn't need a fsck
by c0t0d0s0 on Mon 2nd Nov 2009 22:54 UTC
Member since:

At first a fsck doesn't solve a lot of problem. It checks the filesystem, but not the data. It's called fsck and not datackc for a reason. So we end of with a mountable filesystem, but the data in it ... that's a different story.

With ZFS you can tackle the problem from a different perspective. At first you have to keep two things in mind (sorry, simplifications ahead): ZFS works with transaction groups and ZFS is copy-on-write. Furthermore you have to know that there isn't one uberblock, there are 128 of them, (transaction group number modulo 128 is the uberblock used for a certain transaction group).

Given this points, there is a good chance, that you have an consistent state of your filesystem shortly before the crash and that it hasn't overwritten since due to the COW.

So you just have to rollback the transaction-groups until you have a state that can be scrubbed without errors .... and you have a recovered state that is consistent and with validated integrity. You just lost the last few transactions. That can't be done with a fsck tool. You can't guarantee the the integrity of the data after the system reported back to you, that the filesystem has been recovered.

You may call the results of PSARC 2009/479 something like an fsck tool, but it isn't. It just leverages the transactional behaviour of ZFS to enable other tools to do their work ( )

Just to end it here: ZFS doesn't need a fsck tool, because it doesn't solve the real problem. ZFS needs something better and with all the features of ZFS in conjunction with PSARC 2009/479 it will deliver something better.

Reply Score: 4

RE: ZFS doesn't need a fsck
by Dryhte on Tue 3rd Nov 2009 07:57 in reply to "ZFS doesn't need a fsck"
Dryhte Member since:

Everyone who quotes that link implicitly _agrees_ with the article's premise, which is not that zfs needs 'fsck' but *that zfs needs a way to fix unmountable volumes to the point where they can be imported/mounted again*, in order for the filesystem's self healing capacities to kick in. Please try to read between the lines instead of criticising the author for using the word 'fsck'.

Reply Parent Score: 4