On 30/12/2016 19:54, Gordon Messmer wrote: > On 12/30/2016 02:39 AM, Mayavimmer wrote: >> The plan is to nondestructively >> upgrade the old OS to F25 by keeping both for a while, giving the user >> the option to boot the old OS if they want > > I don't understand how "upgrading" the old OS will be "non destructive" > or give the user the option to boot the old system. Can you clarify? An > upgrade is generally understood to be an in-place operation, in which > case booting the old system would not be an option. 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. When they test and OK the change I'll disable the old boot and remotely start to transfer the 2TB data to the new OS's better data structures, as I mentioned just below. > >> Meanwhile I would slowly move the old data over to new dynamic >> Btrfs raid1, to take advantage of its gorgeous scrub and autorepair >> mechanism. > > As I understand it, those scrub and repair options really work best when > btrfs is directly on top of the individual disk partitions. If you put Yes! (Almost). That is exactly why I am doing this. See below for the "almost" part. > stuff like md RAID underneath btrfs, it loses the ability to detect and > repair some types of errors. For example, if you configure data > mirroring / RAID1 in btrfs, it will write each data block to each disk > with checksum. When you scrub the data, if there was a bit flip or > other error, btrfs can determine which disk has the correct data and > replace the block on the disk where the data is corrupt. If you have > btrfs on top of an abstraction, like md RAID, then btrfs can only > directly access one copy. If the copy is corrupt, btrfs can identify > that as being the case, but it doesn't have the second copy to restore, > so it can't fix the error. md RAID will do its own check and where it > sees mismatching blocks, it doesn't know which is correct and can't > reliably fix the data like btrfs can. Yes, I completely agree. Btrfs over Md cannot scrub autorepair. That's why I want to do Btrfs over LVM instead! > > 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. > >> The installer is confusing to me. Logic would suggest that you choose >> LVM device, then select a Btrfs volume instead of ext4, but there is no >> such option! > > I haven't verified that, but it wouldn't surprise me, for the reasons > described above. The reasons you gave are for Btrfs over Md, and they are good reasons. They do not apply to Btrfs over LVM though. 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. Only I can't coax the F25 installer to do it for me. I think it is getting its volume management and raid roles all mixed up, to "simplify" things. > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
