Re: [PATCH v11 00/20] nfs/nfsd: add support for localio

Chuck Lever III
2024-07-08T14:41:49Z

> On Jul 8, 2024, at 12:10 AM, NeilBrown <neilb@suse.de> wrote:
>
> On Sun, 07 Jul 2024, Chuck Lever III wrote:
>>
>> Both the Linux NFS client and server implement RFC 8154
>> well enough that this could be an alternative or even a
>> better solution than LOCALIO. The server stores an XFS
>> file system on the devices, and hands out layouts with
>> the device ID and LBAs of the extents where file content
>> is located.
>>
>> The fly in this ointment is the need for NFSv3 support.
>
> Another fly in this ointment is that only XFS currently implements that
> .map_blocks export_operation, so only it could be used as a server-side
> filesystem.

I agree that limiting loopback acceleration only to
XFS exports is an artificial and undesirable
constraint.

> Maybe that would not be a barrier to Mike, but it does make it a lot
> less interesting to me (not that I have a particular use case in mind,
> but I just find "local bypass for NFSv4.1+ on XFS" less interesting than
> "local bypass for NFS on Linux").
>
> But my interest isn't a requirement of course.

My focus for now is ensuring that whatever is merged
into NFSD can be audited, in a straightforward and
rigorous way, to give us confidence that it is secure
and respects the existing policies and boundaries that
are configured via export authorization and local
namespace settings.

The pNFS-based approaches have the advantage that a lot
of that auditing has already been done, and by a wider
set of reviewers than just the Linux community. That's
my only interest in possibly excluding NFSv3; I have no
other quibble with the high-level goal of supporting
NFSv3 for loopback acceleration.

Thanks everyone for a spirited and frank discussion.

>> In an earlier email Mike mentioned that Hammerspace isn't
>> interested in providing a centrally managed directory of
>> block devices that could be utilized by the MDS to simply
>> inform the client of local devices. I don't think that's
>> the only possible solution for discovering the locality of
>> storage devices.
>
> Could you sketch out an alternate solution so that it can be assessed
> objectively?

I'll give it some thought.

--
Chuck Lever