RPM Transaction Enhancements
One of the reasons I wanted to revive rcd was so that I could use it to play with some package management ideas I’ve been kicking around. One of these ideas is a way to reliably rollback changes made during an RPM transaction. That is, actually make RPM transactions transactional.
Recently, a colleague introduced me to device-mapper, a kernel system used for block device redirection. There is a really cool thing that uses it called dm-snapshot, which allows you to redirect all writes to a device into a separate device. What I would like to do is use this to store all of the changes made during an rpm transaction. I think it would just need a bit of patching so that it only stores the changes made by the rcd/rpm process (and children). If anything goes wrong, you can just trash the snapshot data and things are exactly as they were in the beginning. Of course, if it succeeds without problelms, you need to merge the snapshot changes into the original device. This is where things get fuzzy, as dm-snapshot does not have this ability. However, Mark McLoughlin has created a set of patches that add this feature as part of the Stateless Linux project. Sadly, the patches do not appear to be a high priority for the kernel guys right now, so I guess this approach will have to be put on hold.
In any case, a system for performing this rollback stuff would be ridiculously useful in general — not just for package management. It looks like it will be a little more than I can do by myself in a weekend hack, though, so hopefully someone else will carry the torch? 
May 4th, 2007 at 9:17 am
I think you’ll have a serious problem using DM for this. Since it operates at the block device level, it has a normal file system mounted on top of it. I don’t really see a good path to isolate individual app changes like this. You’d need a file system capable of doing transactions (like NTFS 5.5).
May 4th, 2007 at 9:22 am
Jerome: Yeah, but couldn’t DM just pass through the writes for the non-snapshotted applications? I am not a kernel hacker, but I assume the kernel has a way of figuring out what process is writing the block, no?
May 4th, 2007 at 9:27 am
[…] James. funny you bring up device-mapper at this point. I am looking into using it for an unbrick my laptop option on the OLPC laptops. One of the things we want to enable is allowing kids to explore and find out how the laptop works. Playing around with the base system is a good way to do that, however a child would run the risk of bricking their machine. Using device mapper we could redirect all of the user’s changes so if they end up making a mistake we can rollback to a known working state. […]
May 4th, 2007 at 9:48 am
Conary (http://wiki.rpath.com/) does transactional system updates and has had rollback support from day one. Might want to check it out. It would probably be a good fit for OLPC.
September 9th, 2007 at 8:19 pm
Hey James - two thoughts:
a) nice work!
b) check out conary - it has transaction rollback, and it looks like Erik covered some further corner cases that RPM does not address
c) User Mode Linux has a similar snapshotting ability, but you cannot separate processes (I know I said TWO, but I am cheating
d) NO, unfortunately in the current kernel you cannot separate writes on a per-process basis (otherwise yours truly or someone else would write the long awaited I/O version of ‘top’ — you currently can only do that in atop (with patches to the kernel), or in systemtap. Bummer.
February 26th, 2008 at 11:07 pm
Not to sound rude, but rpm wasn’t designed to support “atomic transactions” or rollbacks. Conary is a package manager written by the same guy who originally wrote RPM. It supports all of the features he didn’t put in RPM like atomic transactions and rollbacks.
Take a look at what they do with rpath. FYI: I am not affiliated with or working for rpath.