| |||||||||||||
Death, taxes, and fsck?Death, taxes, and fsck?Posted May 4, 2007 9:25 UTC (Fri) by pli (subscriber, #45060)In reply to: Death, taxes, and fsck? by amitgud Parent article: Filesystems: chunkfs and reiser4
Sure, we will always have disks breaking and we will always need tools to fix corrupted filesystems. But isn't this just a matter of how things are implemented. I.e. it seems that ZFS has just chosen to integrate "fsck" into the actual filesystem and improve the way it operates, i.e. on-line/on-the-fly instead of having to unmount the filesystem and run fsck the traditional way.
(Log in to post comments)
Death, taxes, and fsck? Posted May 4, 2007 11:10 UTC (Fri) by qu1j0t3 (guest, #25786) [Link] There is no "on the fly" fsck in ZFS.There is self-healing for data (and some metadata), but as I say above, this does not in itself obviate fsck. The point here is not that ZFS won't ever need a scavenging tool: That debate is ongoing. What is radically new about ZFS is that it's designed to be always correct on disk (which other filesystems don't attempt - possibly excepting XFS, which I haven't studied). It's worth remembering here that ZFS is specifically designed and tested to keep this promise in the face of unexpected system failures (more details from Bill Moore). The concept of fsck has therefore been designed out of the system - rather than regarded as a routine part of filesystem use, as is the case with ext?fs, for example - and if such a tool is ever created, its operation would have little in common with traditional fsck anyway. Please read what Jeff Bonwick has written about the design of ZFS. The other benefit of such study is that you can find out why it's a generation ahead of anything else out there.
|
|||||||||||||