On 12/30/2016 03:38 PM, Mayavimmer wrote:
The upgrade requirement is for the user to revert back and boot the old
OS if it does not work or they don't like it. So the reversible upgrade
cannot be in-place: basically you have both the old and the new OS's
access the common data in a separate partition.
OK. I think that, generally, what you're describing would be referred
to as a fresh install on new partitions, rather than an upgrade. I was
unclear before, but I think I have an idea of what you've planned, now.
If you want to take advantage of it, you probably *really* want to build
an entirely new system.
I don't understand this. I thought I _was_ building an entirely new system.
(That's what confused me. You're building a new system, but you called
it an upgrade. "Upgrade" generally means modifying an existing system,
not building a new one.)
For example, you have two disks, sda and sdb, with lots of partitions.
You create LVM volume group vga out of all the empty partitions on sda,
and similarly vgb out of sdb. Now create LVM logical volumes lva and lvb
out of vga and vgb respectively. Now you got two block devices, which
are just as good as the raw disk partitions you mentioned above for the
purpose of making a Btrfs RAID1 out of. With scrub autorepair included!
This works because you let Btrfs do the RAID1, and LVM only the volume
management. As it should be.
https://btrfs.wiki.kernel.org/index.php/FAQ#Btrfs_has_subvolumes.2C_does_this_mean_I_don.27t_need_a_logical_volume_manager_and_I_can_create_a_big_Btrfs_filesystem_on_a_raw_partition.3F
I can't say there's *no* reason to use LVM under btrfs, but I do find
it difficult to think of a reason why LVM "should be" used for volume
management when it doesn't need to be. Beyond the lack of compelling
advantages, the redundancy in volume and snapshot capabilities (thus,
greater knowledge required), and the performance penalty of LVM, I think
I'd strongly tend to use btrfs without LVM. (BTW: I've spent the last
couple of months measuring LVM's performance impact, and it's a lot
higher than I'd believed. On CentOS 7.2, tests showed that ext4 on md
RAID1 was 100% faster than ext4 on LVM on md RAID1. That situation
improved with 7.3, but I still found it shocking.)
Anaconda/blivet doesn't support every storage configuration possible.
You said you wanted OS vendors to be extra careful, "no funny stuff."
Well, this is what that looks like. The developers only support what
they can test, and if you want something else you'll have to do it
outside of Anaconda. I have to deal with that, myself. For example, md
RAID5 with 512k chunks performs really badly compared to 64k chunks, but
there is no way to specify chunk size to Anaconda/blivet. So, I have to
create the RAID volumes myself if I want them to work well. Likewise,
if you want an exotic storage configuration, you'll probably need to
create the VGs, the LVs, and the btrfs filesystems manually, possibly
from the system that's running now, and then specify to the installer
that you want to use them. That part *should* be possible, even if
creating them inside the installer isn't.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
