On Tue, Sep 8, 2015 at 11:23 AM, Anna Schumaker <anna.schuma...@netapp.com> wrote: > On 09/08/2015 11:21 AM, Pádraig Brady wrote: >> I see copy_file_range() is a reflink() on BTRFS? >> That's a bit surprising, as it avoids the copy completely. >> cp(1) for example considered doing a BTRFS clone by default, >> but didn't due to expectations that users actually wanted >> the data duplicated on disk for resilience reasons, >> and for performance reasons so that write latencies were >> restricted to the copy operation, rather than being >> introduced at usage time as the dest file is CoW'd. >> >> If reflink() is a possibility for copy_file_range() >> then could it be done optionally with a flag? > > The idea is that filesystems get to choose how to handle copies in the > default case. BTRFS could do a reflink, but NFS could do a server side copy > instead. I can change the default behavior to only do a data copy (unless > the reflink flag is specified) instead, if that is desirable. > > What does everybody think?
I think the best you could do is to have a hint asking politely for the data to be deep-copied. After all, some filesystems reserve the right to transparently deduplicate. Also, on a true COW filesystem (e.g. btrfs sometimes), there may be no advantage to deep copying unless you actually want two copies for locality reasons. --Andy -- 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
