Re: making bootup fsck more user-friendly
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
Reply to: