Linked by Pobrecito Hablador on Mon 2nd Nov 2009 21:19 UTC
Thread beginning with comment 393059
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
More News »
Sponsored Links



Member since:
2008-10-16
... i don't like the concept of an fsck out of a completely different reason: With fsck you press you data in the form your filesystem expect. When you are lucky enough, it's the same form your data was before, but most often it isn't.
When you rule out bit rot by checksums, cheap and crappy hardware by transaction rollback, power failure with ZIL and always-consistent on-disk-state, this would leave just software bugs to an fsck. But i think, such problems should be handled in the filesystem itself like enabling the code to read the buggy structure and fix it simply by rewritting it correctly the next time, not with a sideband tool.
The advantage: The fsck just put it into the expected form, a bug fix to the code understands the problem and can do exactly the right steps to fix the bug in the structure and not just pressing it into the expected form.
BTW: I've wrote a rather long piece to this topic in my blog: http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-...