On Thu, 2009-03-26 at 17:19 -0400, James Antill wrote: > On Thu, 2009-03-26 at 20:52 +0200, Jonathan Dieter wrote: > > On Thu, 2009-03-26 at 14:30 -0400, Seth Vidal wrote: > > > > > > On Thu, 26 Mar 2009, Neal Becker wrote: > > > > > > > http://tech.xerces.com/unbreakable-upgrades-zfs-and-apt-get.geek > > > > > > > > > > Here's how this would work in the yum world: > > > > > > 1. if any package from @core (or any of their deps) are being upgraded > > > then run an lvm snapshot and store it/add it to grub > > > 2. proceed with update > > > > > > If anyone would like to write the lvm snapshot rootfs and store/add it to > > > grub I can write the yum plugin to do the rest. > > > > > > It's not radically exciting code. > > > > > > In yum you wouldn't even need to stop the yum update command and ask the > > > user to run a separate program. > > > > My experience with lvm snapshotting was that it slowed down disk speeds > > significantly. I would expect that filesystem based snapshotting (which > > btrfs will have) might be more efficient. Or we could make sure the > > snapshot is only left long enough to make sure the updates work. > > IMNSO the problem isn't the speed hit, it's the fact that you are using > a file system snapshot (or LVM block layer snapshot, same difference) as > a file system transaction. > This is completely insane. Imagine if mysql implemented transactions by > doing a copy of the entire DB, and then for rollback just moved back to > the old version (if you don't see the problem, think about more than one > connection/transaction at once). > > snapshot + rollback can work in some situations, and the yum developers > will be happy to provide some help to people who want to make this > easier to achieve. However even if all the tools made this as automated > as possible, you have to know what you are doing. So, again IMNSHO, this > can't be a general/default solution. Better off having yum ptrace every install process, trap any file interactions, and back those files up into a transaction rollback, also take a list of new files created. Dave. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
