On Fri, Apr 01 2016, Trond Myklebust wrote: > On Thu, Mar 31, 2016 at 1:07 AM, NeilBrown <nfbrown@xxxxxxxxxx> wrote: >> >> On Tue, Mar 22 2016, Christian Robottom Reis wrote: >> >> > On Mon, Mar 21, 2016 at 11:39:14AM -0300, Christian Robottom Reis wrote: >> >> indeed does not return any information pertaining NFS client locks, and >> >> I'm not clear whether /proc/locks (on the server side obviously) does or >> >> not. >> > >> > Somewhat OT, but I find it a PITA that /proc/locks gives inode numbers >> > that then need to be looked up individually. I have often been surprised >> > no tool exists to parse that and give you back a report of filenames, so >> > I just put together a small tool that just offloads the work to debugfs. >> > >> > I've attached it in case others might find it useful. >> >> Nice idea, though it only works with extXfs - better than nothing >> though. >> >> It would be really easy to do this in the kernel. >> I would be very much in favour of a /proc/locks-extended (or whatever) >> that provides the same information as /proc/locks, but in a format >> which includes full path name, process name, and - for nfs locks - >> client name etc. > > Why isn't the current interface sufficient? The 'lslocks' utility > appears quite capable of extracting the full path info. > I don't think I've come across 'lslocks' before - thanks. It does help a bit but when I run it, most of the "PATH" column is empty. Which is odd because I can fill in some of the blanks by cross referencing pid/inode from /proc/locks with inodes numbers from ls -liL /proc/$PID/fd to get full names. Any way, you are right that more information is available if you are willing to hunt around, but not everything. In particular, for locks held by lockd (or NFSv4 locks held by nfsd) it would be nice to know which client host it was held on behalf of. NeilBrown
Attachment:
signature.asc
Description: PGP signature
