An issue when mounting the dd-copied partition and the original one together

An issue when mounting the dd-copied partition and the original one together

[Tydus Ken]

Hi all.

I'm using btrfs for a long time. It's the time for me to report an issu=
e.

I use btrfs for my home and I dded the block device to a new computer.
It works well. But when I tried to mount both up and do syncing
between them, I found the two mountpoints are the same! i.e. when I
touch a file on my original partition, the same file appears in the
new one now. Vice versa.

I wrote a script to replay it (using loop, but result is the same):

=A0 =A0 dd if=3D/dev/zero of=3Dori.img bs=3D16M count=3D16
=A0 =A0 mkfs.btrfs ori.img
=A0 =A0 cp ori.img new.img
=A0 =A0 mkdir ori new
=A0 =A0 mount -o loop ori.img ori
=A0 =A0 mount -o loop new.img new
=A0 =A0 touch ori/foo
=A0 =A0 ls new

You'll see the file `foo' also appears in the `new' directory.

I guess there's something wrong with btrfs in how to deal with two
partition with same UUID or something else, but I'm not sure.

It's proved on Gentoo with Kernel 3.2.11, as well as Ubuntu with Kernel=
 3.1.9

Tydus
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: An issue when mounting the dd-copied partition and the original one together

[Chris Samuel]

[-- Attachment #1: Type: Text/Plain, Size: 1257 bytes --]

On Friday 20 April 2012 16:49:48 Tydus Ken wrote:

> I guess there's something wrong with btrfs in how to deal with two
> partition with same UUID or something else, but I'm not sure.

I don't believe that btrfs can cope with partitions with the same UID.  
A pointer here from Auke in July 2011:

http://marc.info/?l=linux-btrfs&m=131161949201880&w=2

# Resetting the UUID on btrfs isn't a quick-and-easy thing - you
# have to walk the entire tree and change every object. We've got
# a bad-hack in meego that uses btrfs-debug-tree and changes the
# UUID while it runs the entire tree, but it's ugly as hell.
#
# You shouldn't clone btrfs really, just make a new filesystem.

That hack is for an unmounted filesystem, but I don't believe it's 
been shared on this list.

Jan Schmidt was working on a "btrfs send" type command to help with 
this, but I've not heard anything recently (last December he posted 
that he was distracted by the backref-walking code which was a 
necessary precursor for the send/receive code).

cheers,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: An issue when mounting the dd-copied partition and the original one together

[Jan Schmidt]

Hi Chris,

On 20.04.2012 09:20, Chris Samuel wrote:
> Jan Schmidt was working on a "btrfs send" type command to help with 
> this, but I've not heard anything recently (last December he posted 
> that he was distracted by the backref-walking code which was a 
> necessary precursor for the send/receive code).

I still have that in my work queue. Backref walking can be considered
quite stable by now, however it's not guaranteed to be consistent in
every situation when used on live trees. There's only a few corner cases
where it's breaking, but for the qgroup patches, we need to get rid of
those.

btrfs send would operate on read-only snapshots, where I consider
backref walking stable by now. Someone has to push that backref
resolving thing on live trees forward, though. So send/receive is by no
means forgotten about, but further delayed.

-Jan