Btrfs devel - Apr 2012 - An issue when mounting the dd-copied partition and the original one together

Hi all.

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

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

    dd if=/dev/zero of=ori.img bs=16M count=16
    mkfs.btrfs ori.img
    cp ori.img new.img
    mkdir ori new
    mount -o loop ori.img ori
    mount -o loop new.img new
    touch ori/foo
    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

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

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