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." -- 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
