Re: Better interop for NFS/SMB file share mode/reservation

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, May 24, 2019 at 10:12:10AM +0300, Amir Goldstein wrote:
> Some of you may have already seen the reports from my session at LSF/MM
> on Samba/NFS interop: https://lwn.net/Articles/788335/
> 
> It should not be a surprise to anyone here to know that I have had interesting
> and productive conversations with NFS folks about improving samba interop.
> It should not be a surprise to anyone here to know that the rest of the audience
> was, generally speaking, uninterested in the problem.

Eh, especially after a couple days of highly technical talks and people
have trouble focusing on stuff outside their area.  I wouldn't take that
as opposition, if that's what you mean.

I think the only place where there's any entrenched opposition is (alas)
ACLs.

Lease/lock stuff, for example, should be no problem.  It's mainly just a
matter of people finding time.

> Which provides a re-enforcement to the point I was trying to make in session -
> The path of least resistance for NFS-Samba interop is the communicate with
> each other (both human and software wise) and try to leave VFS out of the
> discussion for as much as possible (hence dropping linux-fsdevel from
> this thread).

I've got a strong preference for doing stuff in the VFS.

Maybe the approaches aren't incompatible--if we can do something without
new kernel interfaces for now, it doesn't rule out later moving some of
the logic into the kernel if that helps.

That said, I'm not comfortable depending on an assumption that knfsd and
SMB are the only users of a filesystem.  If we're going to introduce
some new kind of lock, for example, I'd like it enforced against
everyone.  In knfsd, we broke that rule for open deny modes and I think
it was a mistake.

--b.

> An idea that has already been thrown around is to use some samba daemon as
> an arbitrator for opening files and locks. Of course, this would be an
> opt-in feature
> for NFS servers.
> 
> For example, can we use fanotify permission hooks to delegate access control
> checks from knfsd to a daemon?  Right now, the information in
> permission events is
> rather minimal, but as an fanotify developer, I can assure you, that
> we can enrich the
> information passed by knfsd on open permission events if that is deemed useful.
> 
> I will be attending SambaXP, so if any of the Samba guys would like to, we could
> find a slot in the Hallway track or at a local bar to discuss those options.