| |||||||||||||
Death, taxes, and fsck?Death, taxes, and fsck?Posted Apr 28, 2007 1:41 UTC (Sat) by qu1j0t3 (guest, #25786)Parent article: Filesystems: chunkfs and reiser4 Given that filesystem checks are something we have to deal with ...Until something is learned from Reiser{3,4} and ZFS, sure.
(Log in to post comments)
Death, taxes, and fsck? Posted Apr 28, 2007 2:36 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] even with journaling filesystems like reiserfs and zfs you still need to do fsck
reiserfs pretended that you didn't have to, as did XFS, both of them eventually came out with a fsck (or equivalent).
in fact reiserfs3 is especially bad when you do a fsck, it can't tell which superblocks are part of which filesystem and can turn a minor issue into total data loss (triggered if you have an image of a reiserfs stored on a reiserfs when you fsck)
Death, taxes, and fsck? Posted May 3, 2007 12:28 UTC (Thu) by pli (subscriber, #45060) [Link] ZFS doesn't have/need a fsck, according to http://zfs-on-fuse.blogspot.com/2007/04/zfs-in-linux-kern...
Death, taxes, and fsck? Posted May 3, 2007 12:51 UTC (Thu) by boniek (guest, #45061) [Link] Thats right. Chunkfs seems more like workaround to the problem rather than a real solution. ZFS is NOT a journaling filesystem - it checksums all data and can detect and fix corruption on online filesystem - no fsck will be ever needed.
Death, taxes, and fsck? Posted May 3, 2007 13:25 UTC (Thu) by qu1j0t3 (guest, #25786) [Link] Checksumming + redundancy aren't enough to remove the need for fsck, however. One also needs COW & transactional updates.
Until kernel devs actually admit Reiser and/or Sun have actually got it right, Linux will be stuck with fsck for a good while yet.
Death, taxes, and fsck? Posted May 3, 2007 20:21 UTC (Thu) by amitgud (guest, #20655) [Link] Fsck is unavoidable given the imperfect hardware and bugs in the OS and file system alike. Fsck is needed and will be needed from time to time. I/O error trends and the under-estimation of hard drive errors by the manufacturers suggest that as the data get compact on the disk, errors (assuming they do not increase per square inch on the drive as the drives become more complex), will now affect more data on the disk. Disk drives have to be fsck'ed someday, its just the matter of when. And when it is, the time taken will directly affect the availability of the data, and backups do not always help.
Death, taxes, and fsck? Posted May 4, 2007 9:25 UTC (Fri) by pli (subscriber, #45060) [Link] 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.
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.
|
|||||||||||||