Impossible to mount two different copies of the same btrfs
Hi there. Excuse me if I didn't subscribe the list. Just wanted to let you know of this behavior assuming you haven't noticed it yet.
When mounting two copies of the same file system from two different hard disks with the intention of syncing the older with the newer one, btrfs behaves differently from ext4: it will mount the first one twice rather than mounting each. I assume it has something to do with all UUIDs being identical, which doesn't disturb ext4 though.
This only happens with btrfs - I cannot mount two file systems that happen to have the same UUID (or are deemed identical by some other criterion I cannot determine). I presume this is not intended behavior. I tried relabeling one of the copies, but it didn't have any effect. Now I'm looking into ways to change the UUID.
Thanks for the great snapshots however!
Signature · 4 lines
E-mail is public! Talk to me in private using encryption:
http://loupsycedyglgamf.onion/LynX/
irc://loupsycedyglgamf.onion:67/lynX
https://psyced.org:34443/LynX/Quoted 8 lines · carlo von lynX
Hi there. Excuse me if I didn't subscribe the list. Just wanted to let you know of this behavior assuming you haven't noticed it yet.
When mounting two copies of the same file system from two different hard disks with the intention of syncing the older with the newer one, btrfs behaves differently from ext4: it will mount the first one twice rather than mounting each. I assume it has something to do with all UUIDs being identical, which doesn't disturb ext4 though.
I'd say any file system that allows mount without warning when two fs volumes with the same UUID is a bug. I vastly prefer the XFS behavior in this regard which is warn and refusal to mount. You have to use -o nouuid to make it happen; and then I guess there's some separate handling to still keep the fs instances separate, but I don't know how that works at all or how ext4 and Btrfs differ.
Quoted 5 lines
This only happens with btrfs - I cannot mount two file systems that happen to have the same UUID (or are deemed identical by some other criterion I cannot determine). I presume this is not intended behavior. I tried relabeling one of the copies, but it didn't have any effect.
Nope, it really can't work. I haven't tried it but I suspect that with XFS v5 that it's not possible either.
Quoted 1 line
Now I'm looking into ways to change the UUID.
This is in the current version of btrfs-progs with the btrfs-tune command.
Signature · 1 line
Chris Murphy
Quoted 11 lines · Chris Murphy
Quoted 8 lines · carlo von lynX
Hi there. Excuse me if I didn't subscribe the list. Just wanted to let you know of this behavior assuming you haven't noticed it yet.
When mounting two copies of the same file system from two different hard disks with the intention of syncing the older with the newer one, btrfs behaves differently from ext4: it will mount the first one twice rather than mounting each. I assume it has something to do with all UUIDs being identical, which doesn't disturb ext4 though.
Quoted 6 lines
I'd say any file system that allows mount without warning when two fs volumes with the same UUID is a bug. I vastly prefer the XFS behavior in this regard which is warn and refusal to mount. You have to use -o nouuid to make it happen; and then I guess there's some separate handling to still keep the fs instances separate, but I don't know how that works at all or how ext4 and Btrfs differ.
See my other email in this thread. :)
Hugo.
Signature · 4 lines
Hugo Mills | You know... I'm sure this code would seem a lot hugo@... carfax.org.uk | better if I never tried running it. http://carfax.org.uk/ | PGP: E2AB1DE4 |
Thanks for the feedback. I thought I had bumped into a totally excentric use case but really I am making a most average beginner's mistake. I should have noticed when my thinking was in terms of rsync. btrfs-tune would be the hack I first thought of, but I realize that is the wimp's way to go.
So now I'm trying it the btrfs way. I made a fresh snapshot of the current state, created a send file (one gig! ;)) from the previous snapshot. Then I unmounted the source fs and mounted the dest copy. Unfortunately I cannot 'btrfs receive' since I didn't have read-only snapshots and making them from existing ones does not yield the same parent ids.
Looks like I have to format a new target btrfs and start anew with a full snapshot send... then at least I get to use a pipe instead of storing the send on disk. ;)
Quoted 1 line · Hugo Mills
See my other email in this thread. :)
Didn't get that. Should I?
Kind regards for your patience and excellent code!
Signature · 4 lines
E-mail is public! Talk to me in private using encryption:
http://loupsycedyglgamf.onion/LynX/
irc://loupsycedyglgamf.onion:67/lynX
https://psyced.org:34443/LynX/Quoted 13 lines · carlo von lynX
Thanks for the feedback. I thought I had bumped into a totally excentric use case but really I am making a most average beginner's mistake. I should have noticed when my thinking was in terms of rsync. btrfs-tune would be the hack I first thought of, but I realize that is the wimp's way to go.
So now I'm trying it the btrfs way. I made a fresh snapshot of the current state, created a send file (one gig! ;)) from the previous snapshot. Then I unmounted the source fs and mounted the dest copy. Unfortunately I cannot 'btrfs receive' since I didn't have read-only snapshots and making them from existing ones does not yield the same parent ids.
Quoted 3 lines
Looks like I have to format a new target btrfs and start anew with a full snapshot send... then at least I get to use a pipe instead of storing the send on disk. ;)
You need one full send to start off the process. After that, you
can use the incremental feature.
Quoted 4 lines · Hugo Mills
Quoted 1 line
See my other email in this thread. :)
Didn't get that. Should I?
Yes, you should have got it. You were cc'd. It's the one that
starts "Thanks for the thought."
Hugo.
Signature · 4 lines
Hugo Mills | "What's so bad about being drunk?" hugo@... carfax.org.uk | "You ask a glass of water" http://carfax.org.uk/ | Arthur & Ford PGP: E2AB1DE4 | The Hitch-Hiker's Guide to the Galaxy
Quoted 2 lines · carlo von lynX
Hi there. Excuse me if I didn't subscribe the list. Just wanted to let you know of this behavior assuming you haven't noticed it yet.
Thanks for the thought. :)
Quoted 5 lines
When mounting two copies of the same file system from two different hard disks with the intention of syncing the older with the newer one, btrfs behaves differently from ext4: it will mount the first one twice rather than mounting each. I assume it has something to do with all UUIDs being identical, which doesn't disturb ext4 though.
When you have a multi-device filesystem, all of the devices contain
a filesystem with the same UUID (because it's the same filesystem). btrfs therefore uses the UUID to distinguish between filesystems, whereas ext4 can simply use the device ID (major,minor). Create two devices containing a copy of the same filesystem, btrfs sees two devices with the same UUID on them, and decides they're a part of the same FS.
Quoted 5 lines
This only happens with btrfs - I cannot mount two file systems that happen to have the same UUID (or are deemed identical by some other criterion I cannot determine). I presume this is not intended behavior. I tried relabeling one of the copies, but it didn't have any effect. Now I'm looking into ways to change the UUID.
It's well-known behaviour, and documented on the btrfs wiki's
Gotchas page -- first item in the list, in fact. :) Basically, it's likely to give you results somewhere between "doesn't work" and "eats your filesystem, sets fire to your sofa and feeds strychnine to your cat"(*). I can't really recommend trying it.
You can change the UUID offline using a recent (4.1 or later)
version of btrfstune.
Hugo.
(*) No sofas were harmed in the writing of this email.
Signature · 4 lines
Hugo Mills | You know... I'm sure this code would seem a lot hugo@... carfax.org.uk | better if I never tried running it. http://carfax.org.uk/ | PGP: E2AB1DE4 |