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. Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
