On Fri, Sep 09, 2016 at 03:01:46PM +0800, Eryu Guan wrote: > On Thu, Sep 08, 2016 at 11:29:25PM -0700, Darrick J. Wong wrote: > > > > + > > > > +_require_xfs_io_command "copy_range" > > > > > > Do we need to test the support status on kernel side? e.g. what happens > > > if filesystems have no "copy_file_range" implemented? Seems > > > copy_file_range falls back to splice in this case, but I'm not sure. If > > > so I think it's OK to have no kernel side detection. > > > > But... it's a totally new syscall, so _require_io_command should actually try > > calling it so that we can _notrun on old kernels. > > The only reason that I think it's OK to check xfs_io support only is > that the "copy_range" subcommand won't be even compiled in xfs_io if > kernel has no copy_file_range syscall support. It's not uncommon to have an xfs_io that will support a new syscall or syscall flags by directly coding the support when it's not found by the configure script. e.g. io/prealloc.c support for all the different fallocate flags, regardless of whether the underlying kernel or userspace headers support them. > But yeah, I agree that calling it and see how kernel handles it would be > the best option, like how we handle falloc, fpunch in > _require_xfs_io_command. Which we do for precisely the reason above. :P Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
