On Wed, May 15, 2013 at 07:42:51AM +1000, Dave Chinner wrote: > On Tue, May 14, 2013 at 02:15:22PM -0700, Zach Brown wrote: > > I'm going to keep hacking away at this. My next step is to get ext4 > > supporting .copy_range, probably with a quick hack to copy the > > contents of bios. Hopefully that'll give enough time to also integrate > > review feedback. > > Wouldn't the easiest "support all filesystems" hack just be to add > a destination offset parameter to do_splice_direct() and call that > when the filesystem doesn't supply a ->copy_range method? i.e. use > the mechanisms we already have for copying from one file to another > via the page cache as efficiently as possible? Probably; and this in-kernel buffered fallback is particularly desirable for nfsd when the exported fs doesn't provide .copy_range. Having nfsd service the COPY op is still a significant win over having the client move the data backand forth over the wire. But in that quote above I was talking about implementing .copy_range in ext4 as though it could use XCOPY today. I'd like to get a feel for how bad it's going to be to juggle the bio XCOPY IO with unwritten extent conversion, RMW with overlapping existing blocks, i_size advancing, etc. (It's so much like O_DIRECT that I'm already crying a little.) - z -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
