Your message dated Tue, 31 Dec 2013 21:04:51 -0500 with message-id <[email protected]> and subject line Re: fscking after ten years is not useful has caused the Debian Bug report #344940, regarding fscking after ten years is not useful to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 344940: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344940 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: e2fsprogs Version: 1.38+1.39-WIP-2005.12.10-1 Severity: wishlist 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. -- see shy jo
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---tags 344940 +wontfix thanks If you really have an unreliable system clock, you can put the following in e2fsck.conf: [options] broken_system_clock = true Quoting from the man page: broken_system_clock The e2fsck(8) program has some heuristics that assume that the system clock is correct. In addition, many system programs make similar assumptions. For example, the UUID library depends on time not going backwards in order for it to be able to make its guarantees about issuing universally unique ID's. Systems with broken system clocks, are well, broken. However, broken system clocks, particularly in embedded systems, do exist. E2fsck will attempt to use heuristics to determine if the time can not be trusted; and to skip time-based checks if this is true. If this boolean is set to true, then e2fsck will always assume that the system clock can not be trusted. All sorts of other things may go wrong if you insist on relying on a broken system clock. In particular e2fsck's algorithms for detected a busted orphan inode list may get confused. And as described above, UUID's may not longer be "U". - Ted
--- End Message ---
