From: NeilBrown <nfbrown@novell.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Christian Robottom Reis <kiko@acm.org>,
NFS List <linux-nfs@vger.kernel.org>
Subject: Re: Finding and breaking client locks
Date: Fri, 01 Apr 2016 09:40:13 +1100 [thread overview]
Message-ID: <8737r6s242.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <CAHQdGtT+Uwj9zuX+KqB92sVjzcOChvOmr1UDN-ZMQdSURhvWwg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]
On Fri, Apr 01 2016, Trond Myklebust wrote:
> On Thu, Mar 31, 2016 at 1:07 AM, NeilBrown <nfbrown@novell.com> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
prev parent reply other threads:[~2016-03-31 22:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-21 14:39 Finding and breaking client locks Christian Robottom Reis
2016-03-21 17:19 ` Jeff Layton
2016-03-21 17:55 ` Christian Robottom Reis
2016-03-21 20:56 ` Christian Robottom Reis
2016-03-21 21:27 ` Jeff Layton
2016-03-22 0:09 ` Christian Robottom Reis
2016-03-22 0:30 ` J. Bruce Fields
2016-03-31 5:11 ` NeilBrown
2016-03-31 20:52 ` Frank Filz
2016-03-22 0:58 ` Christian Robottom Reis
2016-03-31 5:07 ` NeilBrown
2016-03-31 13:34 ` Trond Myklebust
2016-03-31 22:40 ` NeilBrown [this message]
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=8737r6s242.fsf@notabene.neil.brown.name \
--to=nfbrown@novell.com \
--cc=kiko@acm.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.com \
/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