On Mon, Apr 4, 2016 at 2:50 PM, Kai Krakow <hurikhan77@xxxxxxxxx> wrote: >> Anyway the 2nd 4 is not possible. The seed is ro by definition so you >> can't remove snapshots from the seed. If you remove them from the >> mounted rw sprout volume, they're removed from the sprout, not the >> seed. If you want them on the sprout, but not on the seed, you need to >> delete snapshots only after the seed is a.) removed from the sprout >> and b.) made no longer a seed with btrfstune -S 0 and c.) mounted rw. > > If I understand right, the seed device won't change? So whatever action > I apply to the sprout pool, I can later remove the seed from the pool > and it will still be kind of untouched. Except, I'll have to return it > no non-seed mode (step b). Correct. In a sense, making a volume a seed is like making it a volume-wide read-only snapshot. Any changes are applied via COW only to added device(s). > > Why couldn't/shouldn't I remove snapshots before detaching the seed > device? I want to keep them on the seed but they are useless to me on > the sprout. You can remove snapshots before or after detaching the seed device, it doesn't matter, but such snapshot removal only affects the sprout. You wrote: "remove all left-over snapshots from the seed" The seed is read only, you can't modify the contents of the seed device. What you should do is just delete the snapshots you don't want migrated over to the sprout right away before you even do the balance -dconvert -mconvert. That way you aren't wasting time moving things over that you don't want. To be clear: btrfstune -S 0 mount /dev/seed /mnt/ btrfs dev add /dev/new1 btrfs dev add /dev/new2 mount -o remount,rw /mnt/ btrfs sub del blah/ blah2/ blah3/ blah4/ btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/ btrfs dev del /dev/seed /mnt/ If you're doing any backsup once remounting rw, note those backups will only be on the sprout. Backups will not be on the seed because it's read-only. > > What happens to the UUIDs when I separate seed and sprout? Nothing. They remain intact and unique, per volume. > > I'd now reboot into the system to see if it's working. Note you'll need to change grub.cfg, possibly fstab, and possibly the initramfs, all three of which may be referencing the old volume. > By then, it's > time for some cleanup (remove the previously deferred "trashes" and > retention snapshots), then separate the seed from the sprout. During > that time, I could already use my system again while it's migrating for > me in the background. > > I'd then return the seed back to non-seed, so it can take the role of > my backup storage again. I'd do a rebalance now. OK? I don't know why you need to balance the seed at all, let alone afterward, but it seems like it might be a more efficient replication if you balanced before making it a seed? > > During the whole process, the backup storage will still stay safe for > me. If something goes wrong, I could easily start over. > > Did I miss something? Is it too much of an experimental kind of stuff? I'm not sure where all the bugs are. It's good to find bugs though and get them squashed. I have an idea of making live media use Btrfs instead of using a loop mounted file to back a rw lvm snapshot device (persistent overlay), which I think is really fragile and a lot more complicated in the initramfs. It's also good to take advantage of checksumming after having written an ISO to flash media, where users often don't verify or something can mount the USB stick rw and immediately modify the stick in such a way that media verification will fail anyway. So, a number of plusses, I'd like to see the seed device be robust. > > BTW: The way it is arranged now, the backup storage is bootable by > setting the scratch area subvolume as the rootfs on kernel cmdline, > USB drivers are included in the kernel, it's tested and works. I guess, > this isn't possible while the backup storage acts as a seed device? But > I have an initrd with latest btrfs-progs on my boot device (which is an > UEFI ESP, so not related to btrfs at all), I should be able to use that > to revert changes preventing me from booting. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
