Is it needed/possible to fsck under ZFS ?

Matthew Seaman matthew at FreeBSD.org
Thu Apr 20 15:18:14 UTC 2017


On 2017/04/20 14:42, Manish Jain wrote:
> Under UFS, I always used to do manual fsck upon improper shutdown.
> But I have no idea what to do for ZFS. Is it needed (even possible ?)
> to fsck for ZFS ? I very much doubt that : ZFS was, as far as I know,
> designed with data integrity as a central concern. But still I would
> like to be sure.

Other respondents have pointed you at 'zpool scrub' -- which is fine,
but it isn't an analogue of fsck(8).  'zpool scrub' discovers and
corrects filesystem blocks that fail their checksum tests (assuming some
sort of mirroring / zraid setup or you're saving multiple copies of each
block).  Failures like that are usually down to the hardware not working
perfectly.  It's a unique feature of ZFS -- about the only equivalents
are the 'patrol read' functionality of some high-end RAID controllers,
but those may only /detect/ corruption rather than fixing it.

Anyhow, you don't need anything like fsck(8) with ZFS because ZFS always
keeps what is on disk self-consistent.  It's the Copy-on-write semantics
thing that allows it to do that.  If you edit a file, the modified data
is first written to a new disk block, and then there is an atomic
operation to update the block pointer to point to the newly written
block.  If anything goes wrong in the middle of that sequence, you're
left with the original unchanged version of the file.

The difference effectively is that an unclean shutdown on ZFS may lose
the last few IO transactions, but the filesystem will still be clean and
should work immediately on reboot.  With UFS, you can end up with an
inconsistent filesystem due to interrupted IO transactions, which
requires a scan-and-repair pass by fsck and can result in files being
removed or moved into lost+found.

TL;DR -- don't worry about fsck with ZFS.  It doesn't need any special
treatment after an improper shutdown.

	Cheers,

	Matthew



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 972 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20170420/398c0280/attachment.sig>


More information about the freebsd-questions mailing list