Automatic fsck

[Andrew Sayers]

Phillip Susi wrote:
> The snapshot was never mounted in the first place, so there is no need
> to unmount it.
> 
> As you mentioned before however, any files changed since the snapshot
> was made will be lost when you reboot and merge the snapshot back to the
> main volume.
> 

Either I'm not making myself clear or my lack of kernel mojo is showing.

The test I did previously was on a running filesystem, while it was in
use - not during boot-up as we'd previously discussed.  It seems to me
that a literal snapshot, capturing a random moment in the life of a
filesystem, would be treated by e2fsck as not having been cleanly
unmounted.  Since e2fsck didn't complain about anything like that, some
part of the snapshotting process must cleanly unmount the filesystem.
This means that one can take a snapshot while the system is running,
fsck the snapshot, and (if the snapshot is error-free) conclude that the
main volume doesn't need an automatic check for another few months/reboots.

So building on Lars' idea, I propose:

At boot-time:

1. kernel mounts root filesystem read-only
2. init scripts check which filesystems have passed their max mount
   count/interval
   2a. init scripts snapshot those filesystems
   2b. the main volumes for those systems are mounted
       (without being checked)
3. init scripts continue as normal
4. fsck starts on each snapshot, preferably with "ionice -c3"
5. if a snapshot is found to be clean,
   5a. the main volume has its mount-count/check-time reset
   5b. the snapshot is destroyed
   5c. the user is /not/ informed
6. if a snapshot is found to have problems,
   6a. the main volume is marked to be fsck'd
   6b. the snapshot is destroyed
   6c. the user is asked to reboot

In /etc/cron.weekly/fsck:

1. pick a device in /dev/mapper (i.e. only check one device per week)
2. snapshot that volume
3. continue from (4), above

Since merging is currently in beta, and probably a daft idea in this
context, it's better to roll out something more practical, and think
about being more audacious next time.

Remembering my aforementioned lack of kernel mojo, the biggest problems
I can see with this approach are that it requires Ubiquity to do LVM by
default and to keep a significant chunk of the drive free for snapshots
(off the top of my head, I'd say 1-5% of total disk space).

	- Andrew