Introduction
This is not the main AutoFsck page, that is at the page AutoFsck. This page is the spec which is linked to by the Launchpad blueprint. If you wish to see end user information, or download and use AutoFsck, please visit the main page.
About
AutoFsck a script which automates periodic disk checking in such a way that it no longer bothers the user every 30 boots, and is streamlined in a friendly graphical user interface.
AutoFsck ensures that the automatic disk check will no longer inconvenience you by making your boot times very long.
Rationale
The automatic 30 mount fsck is time consuming, but needed. The problem is that the user never knows how close they are to hitting the 30 mounts, so the long boot delay may come at a very inconvenient time.
Use Cases
Peter doesn't know that he has not run fsck for a while. He has prepared a presentation with Open Office and just turned on his laptop to show it. Peter boots up quickly, gives his presentation and then starts to shut down his laptop. At this point he is told that his disks are signalling that they need checking and asked if he would like it to run the checks when he shuts down. He knows he isn't in a rush so he says yes. His laptop runs fsck and then powers down.
Jane is a student who runs Ubuntu on her laptop. She is late for a lecture and needs to get up and running quickly. AutoFsck makes sure that fsck isn't run on boot. When she shuts down after the lacture she is asked if she would like to run fsck, she is rushing off to the next lecture and so doesn't have time to wait, she selects no. When she shuts down after the next lecture she is prompted again, again she is in a rush and selects no. After using her laptop in the evening, she is prompted a third time, and knowing that she has nowhere urgent to go, says yes. Her laptop runs fsck and powers down.
Melanie runs Ubuntu on her desktop. She needs to quickly copy a file to her USB drive to take to University with her. She copies the file and clicks 'shut down'. She is asked if she wants the computer to run fsck, knowing that she is leaving the house and doesn't need it any more, she says yes, as she leaves it is running fsck and shutting down.
NOTE: The prompt will not refer to fsck, but to checking disks for errors, or something equally user friendly.
Inclusion in Ubuntu
From the activity on the forums regarding the annoyance of the forced disk checks, I feel that AutoFsck, or at least something with it's functionality should be included in the main Ubuntu Distribution as a dependency of Ubuntu-Desktop (as it is of dubious use on the server etc).
The project aim is to include AutoFsck in Gusty Gibbon (7.10)
Technical Details
Coming soon for v3.1
Feedback, Suggestions, Comments etc
If you have any feedback, suggestions or comments, please post them below or email me; jmusther@gmail.com
Feedback/Discussion
PLEASE NOTE - I have removed all comments which made suggestions which have been implemented in 2.0 and 2.5. Similarly, I have removed all comments which are no longer relevant or no longer make sense.
- I wonder if it's possible to move the fsck to be done on shutdown and then have an option to cancel it. So in the dialogue which allows you to select Shutdown, Suspend etc, there's a little note when you're due for an fsck which says 'When you shut down your filesystem will be checked for errors, if this is not a convenient time, click the 'fast shutdown' button'. The 'fast shutdown' button would only need to be available when a disk check is due.
Don't call it 'fast shutdown' because everybody like 'fast' and some people will use this option without reading the warning
I would suggest something like 'Postpone disk check', it's more technical but that's fine - if you don't understand what it is about you should just choose the normal Shutdown and have the disks checked. --TormodVolden
AutoFsck should check to see if the laptop is on battery, and if so, assume that the check should *not* happen on shutdown. Fsck already has logic to check to see if it is on battery on bootup, and to skip the fsck unless the fsck parameters have been exceeded by a gross amount. --TheodoreYTsO
On a someone related note, if the system has the ability to do on-line snapshots using devicemapper, the really right answer is to have a configurable option where a cron script checks to make sure the machine is connected to the AC mains (feel free to steal code from e2fsck for checking for this) and if so, creates an on-line snapshot of the filesystem, and then runs e2fsck -nf on the snapshot. If the filesystem is clean, then tune2fs can be used to adjust the last-checked and number-of-mounts-since-last-checked parameters on the live filesystem. If the filesystem contains errors, the e-mail should be sent to the system administrator(s) so that they can schedule downtime to fix the filesystem with errors. (Optionally, upon configuration the system could be immediately halted or rebooted to force an fsck, depending on the whether the system administrators has some kind of high-availability failover set up for the system, or if the system contains critical applications where it is better to force a reboot and fsck right away, rather than to let the system continue with a partially corrupted filesystem.) --TheodoreYTsO
I'd suggest not creating the /fastboot file. If the check was interrupted for some reason then we do still want to check the filesystems. On the other hand if the check completed ok, then the builtin e2fs metadata should be enough to skip the check next time. There is one remaining window here which is when more than 180 days elapse between shutdown and next bootup, but in that case it's probably reasonable to check. -- MartinPool
I think that should be selectable if the check happens on startup or shutdown. Personally, I prefer at startup, for instance. AdilsonOliveira
Seriously: why can't we just disable the forced fsck every x mounts? Ext is the only filesystem I know of that does this. Windows doesn't do it for fat or ntfs. Reiserfs does not do it. Why does ext still do it? It simply isn't needed in the vast majority of cases, so why inconvinience the user with it? -- PhillipSusi
The original author (tytso, who posted above) feels that periodic checks are a good idea to guard against creeping inconsistency introduced by kernel bugs or hardware errors. Ubuntu should not lightly disable something that upstream strongly feels is a safety measure. If it happened at shutdown it'd be much less of an inconvenience. (Much like the way Windows can install updates before shutting down.) -- MartinPool
I would be very interested to hear (from somebody who knows a lot about filesystems) why it is that ext needs the periodic checking, and other filesystems don't. I suspect that we shouldn't compare ext to FAT, as FAT was quite terrible, and I'm even sceptical about comparing it to NTFS. So, are these other filesystems simply running a risk by not having this behaviour, or is there some design flaw with ext? Also, why are we actually guarding against, if it's kernel bugs and hardware errors (as MartinPool suggests) then surely these would affect any filesystem. Ext is one of the few systems that requires this, but it's also a very solid filesystem, so I'm certainly not going to be quick to dismiss it, and I'm also not going to disable it (incidentally, this can be done by changing the last number on the filesystems line in /etc/fstab, to 0).