Slashdot Mirror
Complete Filesystem Checkpointing?
polymath69 asks: "Living on the edge of Debian unstable means that
updates sometimes break stuff, occasionally to an extent that is
difficult to recover from. This got me thinking about treating the
entire set of mounted filesystems as a transactional database.
Mark state, try something which might be dangerous, test, and approve (commit) or panic (rollback). Obviously some filesystem support would be required, but with ext3 and reiserfs available, maybe the potential is already there. And such a system would need lots of disk space, but these days that's a demand easily granted. There's lots out there on process-level checkpointing, and even some stuff about system-level checkpointing, but all I've found on that was in the context of saving and restoring processes for a system freeze and restore. But I couldn't find anything on Google or SourceForge about doing this sort of temporary branching in the filesystem. Is this idea feasible? Is anyone working on it?"
It's a bit time consuming, but tar has been doing this job for me for a while. I finally (took me a long time, ok) created a working bootable linux CD that mounts my filesystems RO and tarballs the entire contents to a remote server. It takes about 1h20m to do a full backup.
After it finishes, I test software on the existing system. If it breaks I restore, if it doesn't I play-test it for a while and if it keeps behaving I commit it to the next full "state preservation".
The biggest drawback, of course, is that this sceme requires close to 1.5 hours of downtime for the backup and more if you need to restore. But for noncritical systems it works great.
I'm against picketing, but I don't know how to show it.
> Keeping a separate package database in one huge
> (ASCII!) file is advantageous. By being separate
> from the individual packages, the dependencies
> are kept nicely so they can be easily referenced
This is in no way an advantage of the implimentation format being one huge file. It could just as easily be one file per package, or one directory per package and multiple files referencing things like packing list, uninstall commands etc, plus a static, throwaway index file. It makes updates faster and a lot less disaster prone.
> As an ASCII file, any sort of little error
> which might cause a problem is easily
> correctable, as opposed to other packaging
> systems.
That's great until your filesystem decides to truncate it to 0 bytes, and it's lots of fun looking for parse errors 40,000 lines into a file and guessing what might have been in the garbage that you find.
> Regardless, this is not what the article
> submitter was talking about at all.
It is one of the dangers of Debian; upgrade to the latest unstable apt -> nuked package db, upgrade to the latest kernel and get fs corruption -> nuked package db. Find your ATA driver/chipset is buggy on handling large files -> nuked package db. Install a borked package -> nuked package db.
TRAM is just non-volatile solid-state. Slow, but not as slow as a hard drive. Bah.
A cleaner solution to this person's problem would be more robust 'uninstall' functionality in Debian's package manager, to make it clean up its own mess. To 'rollback' a hard drive would not only be time-consuming, but it would require exclusive access to the hard drive for the duration of the rollback. Might as well just make a disk image once everything is running smooth, and rebuild it whenever there are significant changes.
-Billco, Fnarg.com