Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Sep 2020 01:43:08 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Alexander Leidinger <Alexander@leidinger.net>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: RFC: copy_file_range(3)
Message-ID:  <20200923224308.GK2570@kib.kiev.ua>
In-Reply-To: <20200923212135.Horde.KVi_zSxPaGuNqcGzm_Qxani@webmail.leidinger.net>
References:  <CAOtMX2iFZZpoj%2Bap21rrju4hJoip6ZoyxEiCB8852NeH7DAN0Q@mail.gmail.com> <YTBPR01MB39666188FC89399B0D632FE8DD3D0@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> <CAOtMX2gMYdcx0CUC1Mky3ETFr1JkBbYzn17i11axSW=HRTL7OA@mail.gmail.com> <YTBPR01MB3966C1D4D10BE836B37955F5DD3D0@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> <CAOtMX2jHMRD0Hno03f2dqjJToR152u8d-_40GM_%2BBvNPkN_smA@mail.gmail.com> <YTBPR01MB3966BA18F43F7B6353171E67DD380@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> <20200923122401.Horde.uXmEqpCzVbCyXTuyukZeRwU@webmail.leidinger.net> <20200923145615.GH2570@kib.kiev.ua> <20200923212135.Horde.KVi_zSxPaGuNqcGzm_Qxani@webmail.leidinger.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 23, 2020 at 09:21:35PM +0200, Alexander Leidinger wrote:
> Quoting Konstantin Belousov <kostikbel@gmail.com> (from Wed, 23 Sep 2020
> 17:56:15 +0300):
> 
> > On Wed, Sep 23, 2020 at 12:24:01PM +0200, Alexander Leidinger via
> > freebsd-hackers wrote:
> > > Quoting Rick Macklem <rmacklem@uoguelph.ca> (from Wed, 23 Sep 2020 01:18:18
> > > +0000):
> > > 
> > > > Well, I ran some quick benchmarks using the attached programs,
> > > plus "cp" both
> > > > before and with your copy_file_range() patch.
> > > > copya - Does what I think your plan is above, with a limit of 2Mbytes
> > > > for "len".
> > > > copyb -Just uses copy_file_range() with 128Mbytes for "len".
> > > >
> > > > I first created the sparse file with createsparse.c. It is admittedly a
> > > > worst case,
> > > > creating alternating holes and data blocks of the minimum size
> > > supported by
> > > > the file system. (I ran it on a UFS file system created with defaults,
> > > > so the minimum
> > > > hole size is 32Kbytes.)
> > > 
> > > Not related to the topic of changing cp, but related to the topic of
> > > copy_file_range: does nullfs support (as in pass-through to the underlying
> > > FS) copy_file_range?
> > 
> > Nullfs bypasses VOP_COPY_FILE_RANGE() same as any other multi-vp arg
> > VOP.  What makes you think it is different ?
> 
> I understand "bypass" as "does not handle copy_file_range". And from what I
> was understanding in this discussion, each FS-driver needs to be modified to
> support copy_file_range. I've never looked into the nullfs code (and VFS is
> for me some kind of object oriented interface into which FSes can plug into,
> with a generic "I can't do that" for parts of the interface which needs a FS
> specific implementation in case the FS doesn't provide this part), so I do
> not know how it handles the "place A is a portal into place B". Naivly
> speaking I would assume it translates a request for a specific path by
> modifying the path internally, but for that it needs to provide an. I do not
> know how much meta-data needs to be handled / kept in memory / generated for
> this. I had the options "maybe to much for a pass-through", and "maybe not
> too much for a pass-through". To me it makes sense, that nullfs is able to
> handle this (I have a samba server in a jail which has some datasets mounted
> via nullfs, and the same datasets are also mounted into other jails and
> served read-only via a webserver or other kinds of servers, and would be
> usefule if samba could use copy_file_range on nullfs). You could argue that
> my question was more "is nullfs modified to handle copy_file_range", than
> "does it technically pass-through".

Bypass mean that nullfs forwards the call to corresponding VOP of the
lower vnode.  This should be described in D&I book, also see the comment
at the start of null_vnops.c (I did not rechecked it for accuracy).

We have fallback VOP vector that is invoked when filesystem does
not implement some VOP.  In case of copy_file_range VOP, the slot
is filled by vop_stdcopy_file_range() that is a wrapper around
vn_generic_copy_file_range().

AFAIR, only NFS client implements non-default implementation for
copy_file_range() VOP.  So UFS/ZFS/msdosfs use vn_generic_copy_file_range().

All this assumes that invp and outvp belongs to the same filesystem.
If they do not, as was in case of cp /dev/null something, vn_copy_file_range()
directly invokes vn_generic_copy_file_range().  The later is a loop around
VOP_READ() passing buffer to VOP_WRITE(), as somebody could reasonably expect.
invokes 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200923224308.GK2570>