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 4, 2019 at 8:40 AM Zorro Lang <zlang@xxxxxxxxxx> wrote:
>
> 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.

I meant not to deprecate old format, but add support for new format.
There is no ambiguity when parsing either of these formats:

reflink infile src_off dst_off len
reflink infile
reflink -i infile -s src_off -d dst_off -l len
reflink infile -l len

If you *want* to write an xfstest that uses new command format,
see 3996a90a common/rc: check support for xfs_io copy_range -f N

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