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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
