[Ocfs2-devel] copyfile semantics.

[Trond Myklebust]

On Tue, 2009-05-05 at 15:48 -0600, Matthew Wilcox wrote:
> 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.

It is expected to be a feature of NFSv4.2. There is a proposal currently
winding it's way through the IETF that can handle both copyfile() and
reflink() semantics.

I can help to relay the input from this discussion to the people that
are drafting the IETF proposal to ensure that the Linux community
concerns get heard.

Cheers
  Trond