On Fri, Jul 29, 2016 at 02:59:33PM -0400, J. Bruce Fields wrote: > > > I don't see any obvious problem with the nfsd code, other than the > > > obvious issue with large synchronous copies tying up server threads and > > > leaving clients waiting--but maybe we should just see how people end up > > > using it and deal with the problems as they come up. > > I'm still worrying about this, though. > > As a simple stopgap, could we just set *some* maximum on the size of the > copy? Or better yet on the time?--that'd let filesystems with > clone-like features copy the whole file without blocking an nfsd thread > indefinitely in the case of other filesystems. I'm still really worried about corner cases in the copy_file_range syscall and the COPY nfs implementation. When Darrick implemented xfstests support for clone we found various bugs in the existing implementation and corner cases handled different by xfs/btrfs/nfs and the documentation. I'd really like to see something similar for the copy side. Especially as clone should always be a valid implementation for copy as well. -- 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
