Is there now a way to migrate FS without losing shared COW blocks between subvolumes?
btrfs send lets you keep COW blocks within a subvolume.
But if I have lots of backups where subvolumes have shared data, and I need to migrate this to a new filesystem, is there a decent way?
I know I can btrfs device add new drive as raid1, but I'm trying to migrate off an old filesystem that likely wasn't created well. Is there a way to do that?
I guess ideally I'd need btrfs send on a volume level, not subvolume level.
Thanks,
Marc
Signature · 4 lines
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ Marc MERLIN posted on Fri, 12 Feb 2016 19:28:46 -0800 as excerpted:
Quoted 9 lines
btrfs send lets you keep COW blocks within a subvolume.
But if I have lots of backups where subvolumes have shared data, and I need to migrate this to a new filesystem, is there a decent way?I know I can btrfs device add new drive as raid1, but I'm trying to migrate off an old filesystem that likely wasn't created well. Is there a way to do that?
I guess ideally I'd need btrfs send on a volume level, not subvolume level.
Unless I'm mistaken, what you're looking for is btrfs send -c. You're still sending a subvolume, but the -c says to consider the supplied clone- src parameter for just that, cloned, aka shared, sources, and unlike -p parent, multiple such -c cloned-src options are allowed, so...
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Quoted 8 lines · Marc MERLIN
btrfs send lets you keep COW blocks within a subvolume.
But if I have lots of backups where subvolumes have shared data, and I need to migrate this to a new filesystem, is there a decent way?I know I can btrfs device add new drive as raid1, but I'm trying to migrate off an old filesystem that likely wasn't created well. Is there a way to do that?
I guess ideally I'd need btrfs send on a volume level, not subvolume level.
btrfs send -e should accept a long list of subvolumes, or if you have good bashfoo maybe you can have bash hand over the list in the proper subvolume order. This effectively acts like a recursive send. The problem is that right now it's not working. Even if I use fully qualified paths, starting with the top level volume (id5) being mounted, it doesn't work. But that's the only way I know of to do what you want. Otherwise it's with -p and it's pretty tedious to do manually but again, good bashfoo and you can probably automate a loop. Send SV1 manually, then -p SV1 SV2 then -p SV2 SV3 then -p SV3 SV4, and so on. I'm pretty sure -e does that for you but I haven't been able to test it because I can't get it to work.
Signature · 1 line
Chris Murphy
Quoted 12 lines · Duncan
Marc MERLIN posted on Fri, 12 Feb 2016 19:28:46 -0800 as excerpted:
Quoted 9 lines
btrfs send lets you keep COW blocks within a subvolume.
But if I have lots of backups where subvolumes have shared data, and I need to migrate this to a new filesystem, is there a decent way?I know I can btrfs device add new drive as raid1, but I'm trying to migrate off an old filesystem that likely wasn't created well. Is there a way to do that?
I guess ideally I'd need btrfs send on a volume level, not subvolume level.
Quoted 4 lines
Unless I'm mistaken, what you're looking for is btrfs send -c. You're still sending a subvolume, but the -c says to consider the supplied clone- src parameter for just that, cloned, aka shared, sources, and unlike -p parent, multiple such -c cloned-src options are allowed, so...
I had forgotten about that option, thanks for reminding me.
Quoted 10 lines · Chris Murphy
Quoted 8 lines · Marc MERLIN
btrfs send lets you keep COW blocks within a subvolume.
But if I have lots of backups where subvolumes have shared data, and I need to migrate this to a new filesystem, is there a decent way?I know I can btrfs device add new drive as raid1, but I'm trying to migrate off an old filesystem that likely wasn't created well. Is there a way to do that?
I guess ideally I'd need btrfs send on a volume level, not subvolume level.
Quoted 11 lines
btrfs send -e should accept a long list of subvolumes, or if you have good bashfoo maybe you can have bash hand over the list in the proper subvolume order. This effectively acts like a recursive send. The problem is that right now it's not working. Even if I use fully qualified paths, starting with the top level volume (id5) being mounted, it doesn't work. But that's the only way I know of to do what you want. Otherwise it's with -p and it's pretty tedious to do manually but again, good bashfoo and you can probably automate a loop. Send SV1 manually, then -p SV1 SV2 then -p SV2 SV3 then -p SV3 SV4, and so on. I'm pretty sure -e does that for you but I haven't been able to test it because I can't get it to work.
Yeah, indeed that's the only way I know and the one I was trying to avoid, both because I may not remember all the subvolumes that are related, and because it does not take into account me using cp --reflink=always between subvolumes that are otherwise totally separate for most other files.
I realize it's probably not top of the list, but at this point it would be good to have a way to copy an entire btrfs filesystem to another device without playing device add/remove tricks which won't let you use a new/fresh filesystem, or easily migrate off a somewhat damaged filesystem that maybe you mounted with -o recovery,ro
Is there a TODO/Wishlist somewhere this could/should be added to?
Thanks,
Marc
Signature · 4 lines
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/