Theodore Ts'o wrote: > 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.
How about prompting y/n whether to fsck, at least this would make the occasions when it triggers incorrectly a) much less painful b) very obvious. -- see shy jo
signature.asc
Description: Digital signature
