ke, 2008-08-13 kello 18:33 -0400, Phillip Susi kirjoitti: > Andrew Sayers wrote: > <snip> > > I assume that the equivalent of "umount $snapshot" is done within the > > kernel when the snapshot is created, because it gives you a new > > non-mounted block device. It's therefore possible to do fsck from cron. > > The snapshot was never mounted in the first place, so there is no need > to unmount it.
Right. Just to be clear, the following would be a reasonably reasonable scenario for boot-time fsck, in situations in which LVM snapshots are available: * kernel mounts root filesystem read-only * init scripts make LVM copy-on-write snapshot of all filesystems * init scripts re-mount root filesystem read-write, mount any other filesystems * fsck starts on each snapshot, preferably with "ionice -c3" * once a snapshot has been checked, it is destroyed Since the fscks can take a long time, the results can't be reported at boot-time, and an alternative communication channel is needed. For servers, e-mail and syslog seem reasonable. Any problems found with the snapshots will _not_ be fixed in the real filesystem, only in the snapshot. The real filesystem needs to be fixed too. Like Matt suggested, marking the filesystem dirty (so a real fsck is run at next boot) seems like a reasonable way of doing that. For desktops, putting errors into /var/log/background-fsck/foo.log and having something in the GNOME/KDE sessions watch those files and pop up an error message should be feasible. Would that work? -- Ubuntu-devel-discuss mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
