Re: [PATCH v4 3/3] FSD: Fix NFS server hang when there are multiple layout conflicts

[Christoph Hellwig <hch@lst.de>]

On Wed, Nov 19, 2025 at 09:09:04AM -0500, Chuck Lever wrote:
> On 11/19/25 5:05 AM, Christoph Hellwig wrote:
> > On Mon, Nov 17, 2025 at 11:40:22AM -0800, Dai Ngo wrote:
> >>> If a .fence_client callback is optional for a layout to provide,
> >>> timeouts for such layout types won't trigger any fencing action. I'm not
> >>> certain yet that's good behavior.
> >>
> >> Some layout implementation is in experimental state such as block
> >> layout and should not be used in production environment. I don't
> >> know what should we do for that case. Does adding a trace point to
> >> warn the user sufficient?
> > 
> > The block layout isn't really experimental, but really a broken protocol
> > because there is no way to even fence a client except when there is
> > a side channel mapping between the client identities for NFS and the
> > storage protocol.
> 
> Is the protocol broken, or just incomplete, assuming that other
> (unspecified) protocols are necessary to be provided?

I guess it depends on your definition.  There is no shared client
identify between NFS and the storage protocol.  So you need a side
channel communication protocol such as sneakernet to register the
client identities on the server.  And that even assumes you have
a fencing method at that level, which often might not be the case.