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

From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Anna Schumaker <Anna.Schumaker@netapp.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-nfs@vger.kernel.org,
	Linux btrfs Developers List <linux-btrfs@vger.kernel.org>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>, Zach Brown <zab@zabbo.net>,
	Al Viro <viro@zeniv.linux.org.uk>, Chris Mason <clm@fb.com>,
	Michael Kerrisk-manpages <mtk.manpages@gmail.com>,
	andros@netapp.com
Subject: Re: [PATCH v5 8/9] vfs: Add vfs_copy_file_range() support for pagecache copies
Date: Thu, 15 Oct 2015 08:24:51 -0400	[thread overview]
Message-ID: <561F9B13.7020804@gmail.com> (raw)
In-Reply-To: <20151015063621.GA3025@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]

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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]