Hi Liubo

>----Messaggio originale----
>Da: liubo2...@cn.fujitsu.com
>Data: 29/03/2012 3.24

>> Could you elaborate which would be the issue ?
>> "cp --reflink"-ing a file is not different than snapshotting a file. In
>> any case I could mount a snapshot and not the source subvolume.
>We already have a debate about this "cross-link device":

I read the thread, but I didn't find any explanation for which it should be 
dangerous allowing a cross-link device cp--reflink. Christoph Hellwig only 
asked to explain the "btrfs subvolume semantics" to the fsdevel mailing list, 
in order to find "possible" conflict with the standard unix semantics. But 
because the Inode are different from source and dest I cannot see any problem 
(may be I am wrong, but please explain why).

The only fact that should be pointed out is that cross-link device is not 
possible in the general case; btrfs would be an exception. But I think that 
there are very good reasons to allow the btrfs-exception. But, I repeat, I 
didn't find any good reason to do not allow it. 

>"cp --reflink" will use clone feature, which can share data among files, but 
metadata is preserved individually.
>My case is that I can mount both a subvolume and a snapshot via "-o 
subvol=xxx" or "-o subvolid=xxx".

This should not be a problem. My usual setup is to mount a subvolume as root, 
and the real btrfs root inside a subdirectory to allow operation between 
subvolume (like snapshot and/or cp --reflink). Of course if I don't mount the 
btrfs root, I could not perform snapshot and/or cp --reflink.


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

Reply via email to