AutoFsck - Technical Review

[Scott James Remnant]

(Originally posted to the Technical Board, 20th Feburary)

On the train home this evening I was able to perform a detailed
technical review of Jonathan Musther's AutoFsck specification and
implementation.

I think that we are all agreed that the forced fsck on boot when you
have reached an arbitrary number of mounts of the disk is undesirable.
The work done in Ubuntu 8.04 to output progress within usplash and allow
it to be skipped is an improvement, but it's not perfect.  Two obvious
solutions to remove this exist:

(1) run the filesystem check on shutdown when close to the maximum count

(2) get rid of the mount count check altogether


AutoFsck attempts a variant of (1).

I've attempted a fairly thorough review, and it should be emphasised
that not everything here would be considered a blocker - but this should
be the start of a useful discussion.


Licence
-------

AutoFsck is licensed under version 3 of the GNU General Public License,
though other text claims that version 3 or later of the licence may be
used.

This may be a confusion caused by wording, either meets our licensing
requirements and the conflicting claims aren't a problem since they are
compatible.


User Experience
---------------

AutoFsck runs as a gdm PostSession script or kdm Xreset script, if it
detects that the disk will require checking on the next reboot, it
prompts with a dialog box whether you wish to do the check.

An obvious experience problem exists here, this is after you've already
confirmed you want to restart or shutdown the machine.  Many laptop
users will close the lid at this point, entirely unaware that the
computer has asked them a question -- AutoFsck beeps to try and catch
their attention, and has a timeout of two minutes, but this doesn't
correct the underlying problem.

It strikes me that the fact the drives need to be checked should be
included in the actual "Quit" window, not after it.

That this is handled through the display manager means that AutoFsck is
only relevant to desktop computing, Ubuntu Server would be unaffected.


Surprising Behaviour
--------------------

I was surprised to discover that AutoFsck actually doesn't check the
filesystems on shutdown; it reboots your computer and then performs the
check on startup, before shutting down your computer again.

There are a myriad of obvious problems with this approach; the major two
being dual boot scenarios and kernel upgrades.

A non-default option exists to do it after the filesystems are remounted
read-only, and I would be interested to find out from the author what
problems they encountered.


Technical Problems
------------------

AutoFsck is a bash script using zenity to present GUI elements.  The
script doesn't use "set -e" so errors will not be caught, this could
lead to problem circumstances.

GUI elements do not obey the HIG (nitpicking), in particular the buttons
are not labelled with verbs and the dialog contains a lot of text -- it
wasn't obvious to me at first which button did what.

If you decline a filesystem check on shutdown, the boot check is
prevented as well -- this seems counterproductive.

No check on filesystem type is performed, instead tune2fs is run for all
picked filesystems whether or not they are ext2/ext3.  Since we support
installing to other types, they would need to be checked too; or at
least avoided.

No support exists for LVM, software RAID (mdadm) or device mapper (dm)
devices.  In fact, AutoFsck greps the mount output for /dev/hd
and /dev/sd only.  We use LVM for encrypted disks, so this should
definitely be supported.

The check is made regardless of whether the computer is on battery or AC
power; we nominally do not perform filesystem checks whilst on battery
power.  Ironically the text in the dialog asks you to check this
yourself.

update-rc.d is used to put an init script in place (after asking the "do
you want to?" question), but then is tidied up using rm; this should be
unnecessary if update-rc.d is called correctly.

It seems to be impossible to reboot with this in place; if you reboot,
and your filesystem will need to be checked next time, you'd say yes.
Your machine would then reboot for the filesystem check, and then be
halted because it has finished the check.  On reboot, it seems that
nothing needs to be done at all -- since you're getting the check one
way or another anyway.

The post-fsck halt is not done in an ideal place, in fact, unless I'm
mistaken, it lets us enter rc2 and start services before finally halting
the system.

"init RUNLEVEL" shouldn't be used - it should be "telinit RUNLEVEL"


Scott
-- 
Scott James Remnant
scott at canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20080812/9a60cd5b/attachment.pgp