Re: [PATCH v5 8/9] vfs: Add vfs_copy_file_range() support for pagecache copies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2015-10-15 02:36, Christoph Hellwig wrote:
On Wed, Oct 14, 2015 at 03:08:46PM -0400, Austin S Hemmelgarn wrote:
Whether or not reflink is different from a copy is entirely a matter of who
is looking at it.

So what?  I've been trying to explain why clone semantics matter, and
I've not seen a counter argument for that.  I've also explained a couple
times that a valid clone always is a valid copy, and I've only heard
some slight disagreement, and so far none as long as we take the
COPY_FALLOCATE option into account.

Note that all of this also applies to storage devices - any smart array
will do a clone-like operation underneath an XCOPY, but so far SCSI
doesn't provide full clone _semantics_ even if you can emulate a lot of
it using a lot of complexity around ROD tokens.

Similar at the SCSI level you can perform a fallocate-like operation
using the anchor bit in the UNMAP or WRITE SAME commands.

I agree that we shouldn't try to make a reflink by default (less than
intelligent programmers won't read the docs completely, and will make
various stupid assumptions about how this is 'supposed' to work, making the
defaults less ambiguous is a good thing), but it makes sense (at least, it
does to me) to have the ability to say 'make this block of data appear at
this location as well, I don't care how you do it as long as they are
functionally independent for userspace applications'.

Yes, we absolutely should use reflink as a default implementation for
copy where available.

But we also need a clone or reflink interface that only gives us well
specified reflink semantics, and not the much weaker copy semantics.

Ah, I was completely misunderstanding your meaning, sorry about any confusion that I may have caused as a result of this.

My only point with saying we shouldn't reflink by default is that there are many (unintelligent) people who will assume that since the syscall has copy in it's name, that's what it will do; and, while I don't think we should cater to such individuals, it does make sense to have a syscall that says in it's name that it copies data actually do so by default.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux