Re: listing knfsd-held locks and opens

[Bruce Fields <bfields@fieldses.org>]

On Mon, Dec 10, 2018 at 12:49:02PM -0500, Chuck Lever wrote:
> > On Dec 10, 2018, at 12:47 PM, bfields@fieldses.org wrote:
> > In a little more detail, as starting point, I was considering naming
> > each client directory with a small integer, and including files like:
> > 
> > 	info: a text file with
> > 		NFS protocol version
> > 		ascii representation of client address
> > 		krb5 principal if available
> > 
> > 	clientid: NFSv4 client ID; file absent for NFSv2/3 clients.
> > 
> > 	locks: list of locks, following something like the /proc/locks
> > 		format.
> > 
> > 	opens: list of file opens, with access bits, inode numbers,
> > 		device number.
> > 
> > Does that sound reasonable?  Any other ideas?
> 
> How do you plan to make this kernel API namespace-aware?

I may have some details wrong, but:

We associate most of nfsd's state with the network namespace.  The
"nfsd" pseudofilesystem is where I'm thinking I might put this, and it
inherits the network namespace from the process that calls mount and
stores it in the superblock.  So each mount done in a different net
namespace should get its own superblock, its own inodes, etc.  

(I think that's how proc works, too?)

So when you set up containerized nfsd, you mount a new nfsd filesystem
in each container.  And the list of clients visible there should only be
the ones visible to that namespace.

I guess that means that if you share an export across multiple
containers, then if you want to find all the clients locking a given
file, you have to iterate over all the container's "nfsd" mounts.

I suspect that's what we have to do, though.  I mean, the client
addresses, for example, may not even make sense unless you know which
network namespace they come from.

(On the other hand... how does /proc/locks actually work?  Looks to me
like it always lists every lock on the system.  Can it really translate
any process on the system into a pid that makes sense in any container?
I'm not following that, from a brief look at the code.)

--b.