Posted Oct 31, 2012 18:50 UTC (Wed) by paulj (subscriber, #341)
In reply to: Fedora and LVM by dwmw2
Parent article: Fedora and LVM
My killer-app use-case for LVM is doing upgrades to a new root, while preserving ability to boot to the old. I snapshot my existing root, then clone it onto to a new root LV. This allows me to preserve my old root, and be able to fallback to it should something go wrong with the upgrade (which it does - Fedora Linux, perhaps Linux generally, seems to be getting ever more finicky about installed versions of initrd, kernel and inits).
Without LVM, I'd have to do the upgrades in place. With the risk of being fscked if it goes wrong. (Yes, I should burn recovery CDs in advance - Yum upgrade fails catastrophically infrequently enough that I often don't, but frequently enough though that I have lost day+ to reinstall and reconfigure more than once).
Posted Oct 31, 2012 18:54 UTC (Wed) by paulj (subscriber, #341)
[Link]
Oh, this is so useful, that I'm surprised that Fedora doesn't make use of LVM snapshots to do revertable upgrades.
If LVM snapshots could be promoted to writeable LVs, this process would be even easier. There doesn't seem be a way though. Since Solaris switched to ZFS and IPS, it does upgrades this way I think - through writeable snapshots.
Fedora and LVM
Posted Oct 31, 2012 20:11 UTC (Wed) by dtlin (✭ supporter ✭, #36537)
[Link]
Not sure what you mean by "writable LV" – LVM snapshots are already writable. If you want an wholly independent LV – perhaps you could just copy the snapshot to a new LV.
lvconvert --merge merges a snapshot back into the origin, for when you only want the snapshot's contents and not the origin's anymore.
(Hypothetically, at least. I've not yet tried it myself.)
Fedora and LVM
Posted Oct 31, 2012 22:28 UTC (Wed) by paulj (subscriber, #341)
[Link]
They're writable now? That's changed then, and good news for me. Thanks! I'd heard DM might have merge back support somewhere, but hadn't noticed the LVM UI for it was in lvconvert - I've been looking at lvchange the whole time.
Thanks :)
Fedora and LVM
Posted Nov 1, 2012 12:10 UTC (Thu) by Cato (subscriber, #7643)
[Link]
LVM snapshots are as buggy as a very buggy thing ... search "lvm bugs snapshots" for more and see the comment from the schroot developer above. They are also very slow because they multiply number of I/Os required for a changed block.
Seriously, do a lot of testing before you rely on LVM snapshots. Or just use btrfs.
Fedora and LVM
Posted Nov 1, 2012 23:02 UTC (Thu) by agk (subscriber, #23332)
[Link]
> LVM snapshots are as buggy as a very buggy thing
They are pretty robust nowadays: the last kernel race I can recall that could lead to incorrect data was found a few years ago now.
But they are not designed to be efficient if they grow large or if you have many of them; and make sure they never run out of space (use the snapshot_autoextend* lvm.conf settings / --monitor y / dmeventd).
Fedora and LVM
Posted Oct 31, 2012 21:02 UTC (Wed) by dlang (✭ supporter ✭, #313)
[Link]
on my servers, I just do two root partitions and install the new OS into the currently unused parition.
works very well, no LVM needed.
I've also been bit my LVM and mount by UUID several times (did you know that mounting by UUID doesn't work if you have too many drives in your system? at least on some distros)
Fedora and LVM
Posted Nov 1, 2012 3:41 UTC (Thu) by faramir (subscriber, #2327)
[Link]
>On my servers, I just do two root partitions and install the new OS into the currently unused parition.
That's fine for a fresh install. I believe the use case was for a easily revertable upgrade. Not the same thing.
Fedora and LVM
Posted Nov 7, 2012 13:00 UTC (Wed) by emmi3 (subscriber, #62443)
[Link]
But it's not so much different either. I've ben using this "two primary root partition"-setup for quite some time on all my systems at work. Although I usually prefer to reinstall my desktop systems, this is how I would handle the "revertable upgrade" case:
- create an new filesystem with a different label on the unused partition
- copy the old system over
- change the label for the root filesystem in /etc/fstab to the new one (I would also grep through /etc/ for the old label eg. xubuntu1204, debian60, just in case)
- chroot into the new system and install grub to the new root partition and update-grub (or install and reconfigure extlinux... :)
- activate the new and deactivate the old partition
- reboot
If anything goes wrong just reboot into the old root. Using "MBR" this is a simple matter of pressing the shift-key and choosing the right partition at boot time.
Fedora and LVM
Posted Nov 7, 2012 18:26 UTC (Wed) by faramir (subscriber, #2327)
[Link]
That's quite a lot of manual labor for every time you want to do a revertable upgrade. Which if it was easy enough, I think many would want to do for every upgrade.
Setting up LVM (with snapshots for /) might be a bit more difficult during the initial install, but it seems to me it is going to be a lot more convenient in the end.
In either case, you have to have done something up front during the initial install. i.e. Either used LVM or set aside a partition for your second root.
Fedora and LVM
Posted Nov 2, 2012 7:45 UTC (Fri) by Cato (subscriber, #7643)
[Link]
I would far prefer to avoid buggy LVM snapshots, and the fragility of root on LVM that others have mentioned.
There's a simple non-LVM approach I've used a lot, which is to create two root FS partitions - install your current distro on one, then do 'rsync -avH' from one to the other, boot into that one, and do the upgrade there.
Or simply use a good backup tool to make a backup first - a 2TB drive is not much over $100 these days, just use rsnapshot or your preferred backup tool. If you run rsnapshot daily, it will complete very quickly on a root FS that doesn't change very much, and you can then easily do file-restores and inter-day comparisons of config files (not quite as nice as etckeeper but pretty good).
Once btrfs is more mature, its snapshots look really nice, and much faster than LVM's. Of course, backups are a really good idea either way.