linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bfields@fieldses.org (J. Bruce Fields)
To: linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	jlayton@redhat.com
Subject: listing knfsd-held locks and opens
Date: Mon, 10 Dec 2018 12:47:20 -0500	[thread overview]
Message-ID: <20181210174720.GA2925@fieldses.org> (raw)

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.

My concerns are that:

	- I'd like the format to be easily expandable.  The option to
	  create new files seems like it would help.
	- 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?

--b.

             reply	other threads:[~2018-12-10 17:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-10 17:47 J. Bruce Fields [this message]
2018-12-10 17:49 ` listing knfsd-held locks and opens Chuck Lever
2018-12-10 19:00   ` Bruce Fields
2018-12-10 18:12 ` Jeff Layton
2018-12-10 19:23   ` J. Bruce Fields
2018-12-10 19:53     ` J. Bruce Fields
2018-12-10 23:35       ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181210174720.GA2925@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).