Re: [PATCH v2] xfs_io: support splice data between two files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 04, 2019 at 08:20:34AM +0300, Amir Goldstein wrote:
> On Sun, May 19, 2019 at 8:31 PM Zorro Lang <zlang@xxxxxxxxxx> wrote:
> >
> > Add splice command into xfs_io, by calling splice(2) system call.
> >
> > Signed-off-by: Zorro Lang <zlang@xxxxxxxxxx>
> > ---
> >
> > Hi,
> >
> > Thanks the reviewing from Eric.
> >
> > If 'length' or 'soffset' or 'length + soffset' out of source file
> > range, splice hanging there. V2 fix this issue.
> >
> > Thanks,
> > Zorro
> >
> >  io/Makefile       |   2 +-
> >  io/init.c         |   1 +
> >  io/io.h           |   1 +
> >  io/splice.c       | 194 ++++++++++++++++++++++++++++++++++++++++++++++
> >  man/man8/xfs_io.8 |  26 +++++++
> >  5 files changed, 223 insertions(+), 1 deletion(-)
> >  create mode 100644 io/splice.c
> >
> ...
> > +static void
> > +splice_help(void)
> > +{
> > +       printf(_(
> > +"\n"
> > +" Splice a range of bytes from the given offset between files through pipe\n"
> > +"\n"
> > +" Example:\n"
> > +" 'splice filename 0 4096 32768' - splice 32768 bytes from filename at offset\n"
> > +"                                  0 into the open file at position 4096\n"
> > +" 'splice filename' - splice all bytes from filename into the open file at\n"
> > +" '                   position 0\n"
> > +"\n"
> > +" Copies data between one file and another.  Because this copying is done\n"
> > +" within the kernel, sendfile does not need to transfer data to and from user\n"
> > +" space.\n"
> > +" -m -- SPLICE_F_MOVE flag, attempt to move pages instead of copying.\n"
> > +" Offset and length in the source/destination file can be optionally specified.\n"
> > +"\n"));
> > +}
> > +
> 
> splice belongs to a family of syscalls that can be used to transfer
> data between files.
> 
> xfs_io already has several different sets of arguments for commands
> from that family, providing different subset of control to user:
> 
> copy_range [-s src_off] [-d dst_off] [-l len] src_file | -f N -- Copy
> a range of data between two files
> dedupe infile src_off dst_off len -- dedupes a number of bytes at a
> specified offset
> reflink infile [src_off dst_off len] -- reflinks an entire file, or a
> number of bytes at a specified offset
> sendfile -i infile | -f N [off len] -- Transfer data directly between
> file descriptors
> 
> I recently added '-f N' option to copy_range that was needed by a test.
> Since you are adding a new command I must ask if it would not be
> appropriate to add this capability in the first place.
> Even if not added now, we should think about how the command options
> would look like if we do want to add it later.
> I would really hate to see a forth mutation of argument list...
> 
> An extreme solution would be to use the super set of all explicit options:
> 
> splice [-m] <-i infile | -f N> [-s src_off] [-d dst_off] [-l len]
> 
> We could later add optional support for -s -d -l -i flags to all of the
> commands above and then we will have a unified format.

I'd like to see an uniform option format too. When I write this patch,
I don't know which 'format' is *official*, so I have to choose one I prefer
personally. How to decide which one is better?

Another problem is, if we're going to make all these commands' format
to unify, it'll cause incompatible issue, for example xfstests has lots
of cases use xfs_io commands.

Thanks,
Zorro

> 
> Personally, I have no objection that splice could also use the
> "simple" arguments list as you implemented it, since reflink is
> going to have to continue to support this usage anyway.
> 
> Thanks,
> Amir.



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux