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