From: Andreas Dilger <adilger@dilger.ca>
To: "J. Bruce Fields" <bfields@redhat.com>
Cc: linux-nfs <linux-nfs@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
abe@purdue.edu, lsof-l@lists.purdue.edu,
util-linux@vger.kernel.org, Jeff Layton <jlayton@redhat.com>,
James Simmons <uja.ornl@gmail.com>, NeilBrown <neilb@suse.com>
Subject: Re: [PATCH 00/10] exposing knfsd opens to userspace
Date: Thu, 25 Apr 2019 23:08:25 +0200 [thread overview]
Message-ID: <B37B2837-E8C8-41EA-9A2D-3F8B93304FDD@dilger.ca> (raw)
In-Reply-To: <1556201060-7947-1-git-send-email-bfields@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 5103 bytes --]
On Apr 25, 2019, at 4:04 PM, J. Bruce Fields <bfields@redhat.com> wrote:
>
> From: "J. Bruce Fields" <bfields@redhat.com>
>
> The following patches expose information about NFSv4 opens held by knfsd
> on behalf of NFSv4 clients. Those are currently invisible to userspace,
> unlike locks (/proc/locks) and local proccesses' opens (/proc/<pid>/).
>
> The approach is to add a new directory /proc/fs/nfsd/clients/ with
> subdirectories for each active NFSv4 client. Each subdirectory has an
> "info" file with some basic information to help identify the client and
> an "opens" directory that lists the opens held by that client.
>
> I got it working by cobbling together some poorly-understood code I
> found in libfs, rpc_pipefs and elsewhere. If anyone wants to wade in
> and tell me what I've got wrong, they're more than welcome, but at this
> stage I'm more curious for feedback on the interface.
Is this in procfs, sysfs, or a separate NFSD-specific filesystem?
My understanding is that "complex" files are verboten in procfs and sysfs?
We've been going through a lengthy process to move files out of procfs
into sysfs and debugfs as a result (while trying to maintain some kind of
compatibility in the user tools), but if it is possible to use a separate
filesystem to hold all of the stats/parameters I'd much rather do that
than use debugfs (which has become root-access-only in newer kernels).
Cheers, Andreas
> I'm also cc'ing people responsible for lsof and util-linux in case they
> have any opinions.
>
> Currently these pseudofiles look like:
>
> # find /proc/fs/nfsd/clients -type f|xargs tail
> ==> /proc/fs/nfsd/clients/3741/opens <==
> 5cc0cd36/6debfb50/00000001/00000001 rw -- fd:10:13649 'open id:\x00\x00\x00&\x00\x00\x00\x00\x00\x00\x0b\xb7\x89%\xfc\xef'
> 5cc0cd36/6debfb50/00000003/00000001 r- -- fd:10:13650 'open id:\x00\x00\x00&\x00\x00\x00\x00\x00\x00\x0b\xb7\x89%\xfc\xef'
>
> ==> /proc/fs/nfsd/clients/3741/info <==
> clientid: 6debfb505cc0cd36
> address: 192.168.122.36:0
> name: Linux NFSv4.2 test2.fieldses.org
> minor version: 2
>
> Each line of the "opens" file is tab-delimited and describes one open,
> and the fields are stateid, open access bits, deny bits,
> major:minor:ino, and open owner.
>
> So, some random questions:
>
> - I just copied the major:minor:ino thing from /proc/locks, I
> suspect we would have picked something different to identify
> inodes if /proc/locks were done now. (Mount id and inode?
> Something else?)
>
> - The open owner is just an opaque blob of binary data, but
> clients may choose to include some useful asci-encoded
> information, so I'm formatting them as strings with non-ascii
> stuff escaped. For example, pynfs usually uses the name of
> the test as the open owner. But as you see above, the ascii
> content of the Linux client's open owners is less useful.
> Also, there's no way I know of to map them back to a file
> description or process or anything else useful on the client,
> so perhaps they're of limited interest.
>
> - I'm not sure about the stateid either. I did think it might
> be useful just as a unique identifier for each line.
> (Actually for that it'd be enough to take just the third of
> those four numbers making up the stateid--maybe that would be
> better.)
>
> In the "info" file, the "name" line is the client identifier/client
> owner provided by the client, which (like the stateowner) is just opaque
> binary data, though as you can see here the Linux client is providing a
> readable ascii string.
>
> There's probably a lot more we could add to that info file eventually.
>
> Other stuff to add next:
>
> - nfsd/clients/#/kill that you can write to to revoke all a
> client's state if it's wedged somehow.
> - lists of locks and delegations; lower priority since most of
> that information is already in /proc/locks.
>
> --b.
>
> J. Bruce Fields (10):
> nfsd: persist nfsd filesystem across mounts
> nfsd: rename cl_refcount
> nfsd4: use reference count to free client
> nfsd: add nfsd/clients directory
> nfsd: make client/ directory names small ints
> rpc: replace rpc_filelist by tree_descr
> nfsd4: add a client info file
> nfsd4: add file to display list of client's opens
> nfsd: expose some more information about NFSv4 opens
> nfsd: add more information to client info file
>
> fs/nfsd/netns.h | 6 +
> fs/nfsd/nfs4state.c | 228 ++++++++++++++++++++++++++++++---
> fs/nfsd/nfsctl.c | 225 +++++++++++++++++++++++++++++++-
> fs/nfsd/nfsd.h | 11 ++
> fs/nfsd/state.h | 9 +-
> fs/seq_file.c | 17 +++
> include/linux/seq_file.h | 2 +
> include/linux/string_helpers.h | 1 +
> lib/string_helpers.c | 5 +-
> net/sunrpc/rpc_pipe.c | 37 ++----
> 10 files changed, 491 insertions(+), 50 deletions(-)
>
> --
> 2.20.1
>
Cheers, Andreas
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]
next prev parent reply other threads:[~2019-04-25 21:08 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-25 14:04 [PATCH 00/10] exposing knfsd opens to userspace J. Bruce Fields
2019-04-25 14:04 ` [PATCH 01/10] nfsd: persist nfsd filesystem across mounts J. Bruce Fields
2019-04-25 14:04 ` [PATCH 02/10] nfsd: rename cl_refcount J. Bruce Fields
2019-04-25 14:04 ` [PATCH 03/10] nfsd4: use reference count to free client J. Bruce Fields
2019-04-25 14:04 ` [PATCH 04/10] nfsd: add nfsd/clients directory J. Bruce Fields
2019-04-25 14:04 ` [PATCH 05/10] nfsd: make client/ directory names small ints J. Bruce Fields
2019-04-25 14:04 ` [PATCH 06/10] rpc: replace rpc_filelist by tree_descr J. Bruce Fields
2019-04-25 14:04 ` [PATCH 07/10] nfsd4: add a client info file J. Bruce Fields
2019-04-25 14:04 ` [PATCH 08/10] nfsd4: add file to display list of client's opens J. Bruce Fields
2019-04-25 18:04 ` Jeff Layton
2019-04-25 20:14 ` J. Bruce Fields
2019-04-25 21:14 ` Andreas Dilger
2019-04-26 1:18 ` J. Bruce Fields
2019-05-16 0:40 ` J. Bruce Fields
2019-04-25 14:04 ` [PATCH 09/10] nfsd: expose some more information about NFSv4 opens J. Bruce Fields
2019-05-02 15:28 ` Benjamin Coddington
2019-05-02 15:58 ` Andrew W Elble
2019-05-07 1:02 ` J. Bruce Fields
2019-04-25 14:04 ` [PATCH 10/10] nfsd: add more information to client info file J. Bruce Fields
2019-04-25 17:02 ` [PATCH 00/10] exposing knfsd opens to userspace Jeff Layton
2019-04-25 20:01 ` J. Bruce Fields
2019-04-25 18:17 ` Jeff Layton
2019-04-25 21:08 ` Andreas Dilger [this message]
2019-04-25 23:20 ` NeilBrown
2019-04-26 11:00 ` Andreas Dilger
2019-04-26 12:56 ` J. Bruce Fields
2019-04-26 23:55 ` NeilBrown
2019-04-27 19:00 ` J. Bruce Fields
2019-04-28 22:57 ` NeilBrown
2019-04-27 0:03 ` NeilBrown
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=B37B2837-E8C8-41EA-9A2D-3F8B93304FDD@dilger.ca \
--to=adilger@dilger.ca \
--cc=abe@purdue.edu \
--cc=bfields@redhat.com \
--cc=jlayton@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=lsof-l@lists.purdue.edu \
--cc=neilb@suse.com \
--cc=uja.ornl@gmail.com \
--cc=util-linux@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).