DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6FFF320851
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: listing knfsd-held locks and opens
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <20181210174720.GA2925@fieldses.org>
Date:   Mon, 10 Dec 2018 12:49:02 -0500
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        linux-fsdevel@vger.kernel.org, Jeff Layton <jlayton@redhat.com>
Content-Transfer-Encoding: 7bit
Message-Id: <08F6A3D9-6FF3-452A-BCD6-390ECA142136@oracle.com>
References: <20181210174720.GA2925@fieldses.org>
To:     Bruce Fields <bfields@fieldses.org>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On Dec 10, 2018, at 12:47 PM, bfields@fieldses.org 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.
> 
> 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?

How do you plan to make this kernel API namespace-aware?

--
Chuck Lever