https://bugzilla.novell.com/show_bug.cgi?id=304641#c30
Jeff Mahoney changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |ASSIGNED
Info Provider|jeffm@novell.com |
--- Comment #30 from Jeff Mahoney 2007-11-26 08:00:00 MST ---
The problem here is that corruption can be introduced by other sources than
crashing unexpectedly, but crashing has been the most common source of it.
Journaling file systems remove crashing from the picture by maintaining a
consistent metadata structure that doesn't need to be checked before mounting.
An occasional fsck as needed is a good thing to catch these other sources of
corruption, but running it on _every_ boot is totally overkill and is the
source of these boot delays. On either file system, if we hit corruption at
runtime, we'll catch an error and go read-only. A fsck would be required
afterwards. So the big question is whether adding a huge delay to *every* boot
is worth the very occasional externally introduced corruption. 5 9's don't
survive very long with 15 minute delays on boot for huge file systems.
ext3 doesn't have this problem since it has superblock fields that define how
frequently (in mount count and elapsed time) fsck should run on boot.
I wrote the dynamic bitmap patches specifically to remove the delay in the
mount itself, and now reiserfsck reintroduces it. It wouldn't be too difficult
to add support to reiserfs, but we'd need mainline support for it first. Older
fscks would still run on every boot, but a newer fsck could examine the fields
to determine if it needs checking. 0, expired, or future timestamps could all
be interpreted as "needs checking" so we'd be safe even if those fields weren't
zeroed out as they should be. Only very old file systems would not have them
zeroed out.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.