[mythtv-users] MythTV 0.23 Available

[Brian J. Murrell]

On Tue, 2010-05-11 at 13:26 -0500, Richard Shaw wrote: 
> 
> Here I was really asking a separate question. How does this work in
> the specific case of upgrading Myth? Do you upgrade the original
> system or the snapshot?

I guess it depends on your goal/philosophy.  Personally, I take the
snapshot and then upgrade the original (called the origin in LVM
nomenclature) on the assumption that I will like the upgrade and at some
point just delete the snapshot.

You could do it the other way around, upgrading the snapshot if you just
wanted to test the upgrade in a "sandbox" before doing the real upgrade.
I personally don't see the point in that give that if I don't like the
upgrade I just reboot the snapshot and deal with fixing the origin
rather than doing a whole new upgrade on it.  But I am a hacker.

The problem with upgrading the snapshot is that if you like it and want
it to be your real system, you then have to copy (as in dd) the snapshot
device into an origin as a snapshot will always be a snapshot and depend
on the origin.

I have come to understand that the latest LVM code has support for
collapsing a snapshot back into the origin so that makes the idea of
upgrading the snapshot and then promoting it to the origin if you are
happy more of a reality.

> If you upgrade the snapshot and things go
> wrong, I see how that would be helpful. You can drop the snapshot and
> go back to where you were.

Right.  But if things go right, you are stuck with your running system
in a snapshot of the origin.  Unless you can collapse it into the
origin.  This is the new feature I was mentioning above that I have not
yet investigated.

> If the upgrade goes right, how do you merge
> the difference with the original file system? Or do you?

Indeed.  This is the reason I upgrade the origin.  I work from an
optimistic POV that I will like the upgrade and will delete the
snapshot.  For your use-case (which I agree is probably more useful if
you can indeed merge/collapse the snapshot back into the origin).

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20100511/567d66f1/attachment.pgp>