On Tue, Dec 27, 2005 at 01:26:03PM -0500, Joey Hess wrote:
> Package: e2fsprogs
> Version: 1.38+1.39-WIP-2005.12.10-1
>
> There are several situations where the last fsck time of the filesystem
> can be absurdly long ago, like ten years. I don't think that it's useful
> to fsck in any of these situations. Most common is some issue with the
> hardware clock being broken or not read (bugs #342887, #344818). Less
> common is a disk that has been powered off for ten years.
>
> I think that it would be better than the current behavior if fsck had a
> special case that detected a very long interval between fscks and
> displayed a message like this:
>
> It's been more than ten years since last fsck. Either your clock is busted
> or this drive has not spun up in forever and fscking it would probably
> destroy it anyway. Skipping fsck.
>
If the hardware clock is busted, or incorrect, the filesystem check
would always be skipped. And if the system administrator never
bothers to look at the boot logs, this situation could go undetected
for a long, long, __long__ time, until data is lost.
What fsck has traditionally done in these cases is to simply halt the
boot, since there is no other guaranteed way of getting the system
administrator's attention. Arguably there ought to be, and perhaps it
should also be configurable whether or not to allow the system to come
up after taking some number of files (possibly including files such
has /etc/hosts.deny whose absense could have either security
implications or could cause the system not to function correctly) and
putting them in lost+found.
As far as not spinning up the drive after ten years, in order to
determine that the disk hasn't been used in that long, we have to spin
it up in order to read from the superblock in the first place.... and
if we skip the fsck, it's going to get mounted which will likely
destroy the disk the next time cron tries to update locatedb, or do
something else which scans the disk. So again, the right answer in
such a case might not be to skip the fsck, but to actually abort the
boot.
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
