Re: copyfile semantics.

[Matthew Wilcox <matthew@wil.cx>]

On Tue, May 05, 2009 at 03:44:54PM -0600, Andreas Dilger wrote:
> > When implemented in the filesystem itself, copyfile() can be quite nice.
> > The filesystem can create a temporary inode without visibly exposing it
> > to userspace.  It can delete temporary inodes in journal replay after a
> > crash.  And depending on the fs design, the read/write loop can be
> > replaced with finer-grained reference counting.
> 
> I would think that copyfile() is of primary interest when it involves
> a network filesystem, so there is no need to ship data to the client
> doing the copy at all.  This is possible for NFS and CIFS protocol today,
> AFAIK.  The problem with splice is that the filesystem only knows about
> ->splice_read() and ->splice_write(), it doesn't have any opportunity
> to optimize this further (e.g. by sending a "copyfile" RPC, or implementing
> a reflink or whatever).

Do you mean NFSv4?  I don't know of a way to do it with traditional NFS.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."