Impossible to mount two different copies of the same btrfs

Impossible to mount two different copies of the same btrfs

[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.

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!


-- 
  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/

Re: Impossible to mount two different copies of the same btrfs

[Chris Murphy]

On Thu, Aug 27, 2015 at 11:32 AM, carlo von lynX
<lynX@time.to.get.psyced.org> wrote:
> 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.


> 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.

> Now I'm looking into ways to change the UUID.

This is in the current version of btrfs-progs with the btrfs-tune command.



-- 
Chris Murphy

Re: Impossible to mount two different copies of the same btrfs

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

On Thu, Aug 27, 2015 at 07:32:29PM +0200, carlo von lynX wrote:
> 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. :)

> 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.

> 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.

-- 
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          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Impossible to mount two different copies of the same btrfs

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

On Thu, Aug 27, 2015 at 11:53:28AM -0600, Chris Murphy wrote:
> On Thu, Aug 27, 2015 at 11:32 AM, carlo von lynX
> <lynX@time.to.get.psyced.org> wrote:
> > 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.

   See my other email in this thread. :)

   Hugo.

-- 
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          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Impossible to mount two different copies of the same btrfs

[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.

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.  ;)



On Thu, Aug 27, 2015 at 05:59:47PM +0000, Hugo Mills wrote:
>    See my other email in this thread. :)

Didn't get that. Should I?


Kind regards for your patience and excellent code!


-- 
  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/

Re: Impossible to mount two different copies of the same btrfs

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

On Thu, Aug 27, 2015 at 08:44:15PM +0200, carlo von lynX wrote:
> 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.  ;)

   You need one full send to start off the process. After that, you
can use the incremental feature.

> On Thu, Aug 27, 2015 at 05:59:47PM +0000, Hugo Mills wrote:
> >    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.

-- 
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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]