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": >http://comments.gmane.org/gmane.comp.file-systems.btrfs/9864 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. >thanks, >liubo Ciao Goffredo -- 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
