On Fri, 13 Jun 2008, charlie derr wrote: > Henrique de Moraes Holschuh wrote: >> On Fri, 13 Jun 2008, Johannes Wiedersich wrote: >>> I guess the defaults are very conservative settings regarding >>> reliability of your data and were implemented at a time when there was >>> no journalling for data protection. >> >> Actually, kernel bugs, memory problems, corruption in the CPU to disk >> platter path, and media bitrot are the reasons for which scheduled fsck >> exist. Journals don't help or hinder it in any way. >> >> Otherwise, you'd fsck only on unclean shutdown, or after a known >> data-trashing event (like an erroneous write access to the raw device, or IO >> errors on the device, etc). > > I'd love an explanation about why only certain filesystem types seem to > "need" this fsck as a regular event. Maybe I've got some details wrong,
The only thing that makes periodic fsck rarely needed is a filesystem which uses strong enough CRC or ECC to protect ***all*** of its metadata, and for those with logs and journals, this ALSO requires it to deal properly with all possible failure modes for replay (otherwise it will corrupt itself). You'd still need to fsck it every time you suspect of kernel bugs in the filesystem code. A filesystem that does live fsck (not just data integrity testing, but an actuall full filesystem metadata integrity check like fsck does) is just doing the periodic fsck for you anyway, so it doesn't count. As an example: XFS has extremely well made test suites that SGI runs on the code in the kernel, so bugs (nowadays) are very rare in mainline *releases* (not -rc!). That doesn't mean your hardware will take care of the data XFS entrusted to it as it should have. We are NOT using it on high-end SGI hardware, after all. AFAIK, none of the for-production filesystems have full metadata protection yet, or live fsck capabilities. But I really might be wrong about this, so let's see if someone who knows better can point us to filesystems with that feature. But DO note that you can't have it both ways. The more resilient and safe a filesystem tries to be, the SLOWER it will have to be in order to enforce that. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
