another interesting idea (zfs based upgrades)

James Antill james at fedoraproject.org
Thu Mar 26 21:19:05 UTC 2009


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.

-- 
James Antill - james at fedoraproject.org
"I'd just like to see a realistic approach to updates via
 packages." -- Les Mikesell




More information about the fedora-devel-list mailing list