Chris Mason wrote: > The btrfs implementation is just that you have two separate files > pointing to the same extents on disk. Each file has a reference on each > extent, and deleting or chowning fileA doesn't change the metadata in > fileB. > > The btrfs cow code makes sure that modifications in either file (even > when mounted in -o nodatacow) are written to new extents instead of > changing the original. If you write one block in a 1TB file, the new > space used by the clone is only one block. (Thanks to the ceph > developers for coding all of this up a while ago). Ooh, nice. > The main difference between reflink and the btrfs ioctl is that in the > btrfs ioctl the destination file must already exist. The btrfs code can > also do range replacements in the destination file, but I'd agree with > Joel that we don't want to toss the kitchen sink into something nice and > clean like reflink. Ah, now that I know about the BTRFS data-cloning ioctl... :-) I'm wondering why reflink() is needed at all. Can't it be done in userspace, using the BTRFS ioctl? The hard part in userspace seems to be copying the file attributes, but "cp -a" and other tools manage. What is the advantage of adding the system call for the special case of reflink(), when we choose not to have, say, a copyfile() system call which does what "cp -a" does because doing it in user space is good enough? -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
