DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BE6A720672
Message-ID: <0ff22d33d5d7d2b3fad241ebb2aa0e5c5cb70396.camel@redhat.com>
Subject: Re: listing knfsd-held locks and opens
From:   Jeff Layton <jlayton@redhat.com>
To:     "J. Bruce Fields" <bfields@fieldses.org>,
        linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Date:   Mon, 10 Dec 2018 13:12:31 -0500
In-Reply-To: <20181210174720.GA2925@fieldses.org>
References: <20181210174720.GA2925@fieldses.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 (3.30.2-2.fc29) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On Mon, 2018-12-10 at 12:47 -0500, J. Bruce Fields wrote:
> We've got a long-standing complaint that tools like lsof, when run on an
> NFS server, overlook opens and locks held by NFS clients.
> 
> The information's all there, it's just a question of how to expose it.
> 
> Easiest might be a single flat file like /proc/locks, but I've always
> hoped we could do something slightly more structured, using a
> subdirectory per NFS client.
> 
> Jeff Layton looked into this several years ago.  I don't remember if
> there was some particular issue or if he just got bogged down in VFS
> details.
> 

I think I had a patch that generated a single flat file for locks, but
you wanted to present a directory or file per-client, and I just never
got around to reworking the earlier patch.

> My concerns are that:
> 
> 	- I'd like the format to be easily expandable.  The option to
> 	  create new files seems like it would help.

Yes. We do need to bear in mind that someone will eventually write
scripts to scrape this info. We may want to consider this a formal part
of kernel ABI from the get-go and tread carefully when making changes
after the initial merge.

> 	- some of the data we'd like to expose may be kind of cumbersome
> 	  include as a column in a text file.  (I'm thinking of the
> 	  NFSv4 client identifier, which the protocol allows to be up to
> 	  1K of binary data, even if most (all?) clients use shorter
> 	  ascii identifiers.)
> 
> I'm not sure I'd want to go as far as a sysfs-like one-value-per-file
> rule, which seems like overkill?
> 
> 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?
> 

That sounds like a great start. Some ideas:

The locks file could also list delegations and layouts, but it might be
good to do them in separate files. That would make it cleaner to display
info that is only relevant to those types (recall info, in particular).

You might also consider adding a v4-specific info file. Show things like
"when was last lease renewal"?
-- 
Jeff Layton <jlayton@redhat.com>