Re: [PATCH v13 19/19] nfs: add FAQ section to Documentation/filesystems/nfs/localio.rst

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

 



On Tue, 27 Aug 2024, Trond Myklebust wrote:
> > 
> > 
> > > On Aug 25, 2024, at 9:56 PM, NeilBrown <neilb@xxxxxxx> wrote:
> > > 
> > > While I'm not advocating for an over-the-wire request to map a
> > > filehandle to a struct nfsd_file*, I don't think you can
> > > convincingly
> > > argue against it without concrete performance measurements.
> > 
> 
> What is the value of doing an open over the wire? What are you trying
> to accomplish that can't be accomplished without going over the wire?

The advantage of going over the wire is avoiding code duplication.
The cost is latency.  Obviously the goal of LOCALIO is to find those
points where the latency saving justifies the code duplication.

When opening with AUTH_UNIX the code duplication to determine the
correct credential is small and easy to review.  If we ever wanted to
support KRB5 or TLS I would be a lot less comfortable about reviewing
the code duplication.

So I think it is worth considering whether an over-the-wire open is
really all that costly.  As I noted we already have an over-the-wire
request at open time.  We could conceivably send the LOCALIO-OPEN
request at the same time so as not to add latency.  We could receive the
reply through the in-kernel backchannel so there is no RPC reply.

That might all be too complex and might not be justified.  My point is
that I think the trade-offs are subtle and I think the FAQ answer cuts
off an avenue that hasn't really been explored.

Thanks,
NeilBrown




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux