From: Chuck Lever <chuck.lever@oracle.com>
To: Bruce Fields <bfields@fieldses.org>
Cc: Bill Baker <Bill.Baker@oracle.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v2 00/27] NFSD operation monitoring tracepoints
Date: Fri, 25 Sep 2020 13:04:55 -0400 [thread overview]
Message-ID: <551339D6-2109-487D-8279-746BCA106893@oracle.com> (raw)
In-Reply-To: <BEF0E50C-A658-4AAA-BCBD-49F442A338B5@oracle.com>
> On Sep 25, 2020, at 11:05 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>
>
>
>> On Sep 25, 2020, at 11:00 AM, Bruce Fields <bfields@fieldses.org> wrote:
>>
>> On Fri, Sep 25, 2020 at 10:36:42AM -0400, Chuck Lever wrote:
>>>
>>>
>>>> On Sep 25, 2020, at 10:32 AM, Bruce Fields <bfields@fieldses.org> wrote:
>>>>
>>>> On Fri, Sep 25, 2020 at 09:59:51AM -0400, Chuck Lever wrote:
>>>>> Thanks Bruce, for your time, attention, and comments!
>>>>>
>>>>>> On Sep 24, 2020, at 5:36 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>>>>>>
>>>>>> On Mon, Sep 21, 2020 at 02:10:49PM -0400, Chuck Lever wrote:
>>>>>>> As I've been working on various server bugs, I've been adding
>>>>>>> tracepoints that record NFS operation arguments. Here's an updated
>>>>>>> snapshot of this work for your review and comment.
>>>>>>>
>>>>>>> The idea here is to provide a degree of NFS traffic observability
>>>>>>> without needing network capture. Tracepoints are generally lighter-
>>>>>>> weight than full network capture, allowing effective capture-time
>>>>>>> data reduction:
>>>>>>
>>>>>> I do wonder when tracepoints seem to duplicate information you could get
>>>>>> from network traces, so thanks for taking the time to explain this. It
>>>>>> makes sense to me.
>>>>>>
>>>>>> The patches look fine. The only one I'm I'm on the fence about is the
>>>>>> last with the split up of the dispatch functions. I'll ask some
>>>>>> questions there....
>>>>>
>>>>> To be clear to everyone, this series is still "preview". I expect
>>>>> more churn in these patches, thus I don't consider the series ready
>>>>> to be merged by any stretch.
>>>>
>>>> OK!
>>>>
>>>> One thing I was wondering about: how would you limit tracing to a single
>>>> client, say if you wanted to see all DELEGRETURNs from a single client?
>>>> I guess you'd probably turn on a tracepoint in the receive code, look
>>>> for your client's IP address, then mask the task id to match later
>>>> nfs-level tracepoints. Is there enough information in those tracepoints
>>>> (including network namespace) to uniquely identify a client?
>>>
>>> Client IP address information is in the RPC layer trace data. The
>>> DELEGRETURN trace record includes client ID. So maybe not as
>>> straightforward as it could be.
>>
>> I guess what I meant was "limit tracing to a single network endpoint",
>> not exactly limt to a single NFSv4 client.... So, we can do that as
>> long as all the relevant information is in rpc-layer tracepoints, and as
>> long as task id is a reliable way to match up trace points.
>>
>> Is the network namespace in there anywhere? It looks like there'd be no
>> way to distinguish clients in different namespaces if they had the same
>> address.
>
> The client ID has the boot verifier for the net namespace.
>
> None of this helps NFSv3, though.
It probably wouldn't be difficult to stuff the client IP address
and the boot verifier in the trace record for each procedure.
Do you think that would be sufficient?
--
Chuck Lever
next prev parent reply other threads:[~2020-09-25 17:05 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 18:10 [PATCH v2 00/27] NFSD operation monitoring tracepoints Chuck Lever
2020-09-21 18:10 ` [PATCH v2 01/27] NFS: Move generic FS show macros to global header Chuck Lever
2020-09-21 18:11 ` [PATCH v2 02/27] NFS: Move NFS protocol display " Chuck Lever
2020-09-21 18:11 ` [PATCH v2 03/27] NFSD: Add SPDX header for fs/nfsd/trace.c Chuck Lever
2020-09-21 18:11 ` [PATCH v2 04/27] SUNRPC: Move the svc_xdr_recvfrom() tracepoint Chuck Lever
2020-09-21 18:11 ` [PATCH v2 05/27] SUNRPC: Add svc_xdr_authenticate tracepoint Chuck Lever
2020-09-21 18:11 ` [PATCH v2 06/27] lockd: Replace PROC() macro with open code Chuck Lever
2020-09-21 18:11 ` [PATCH v2 07/27] NFSACL: " Chuck Lever
2020-09-21 18:11 ` [PATCH v2 08/27] SUNRPC: Make trace_svc_process() display the RPC procedure symbolically Chuck Lever
2020-09-21 18:11 ` [PATCH v2 09/27] NFSD: Clean up the show_nf_may macro Chuck Lever
2020-09-21 18:11 ` [PATCH v2 10/27] NFSD: Remove extra "0x" in tracepoint format specifier Chuck Lever
2020-09-21 18:11 ` [PATCH v2 11/27] NFSD: Constify @fh argument of knfsd_fh_hash() Chuck Lever
2020-09-21 18:11 ` [PATCH v2 12/27] NFSD: Add tracepoint in nfsd_setattr() Chuck Lever
2020-09-21 18:11 ` [PATCH v2 13/27] NFSD: Add tracepoint for nfsd_access() Chuck Lever
2020-09-21 18:12 ` [PATCH v2 14/27] NFSD: nfsd_compound_status tracepoint should record XID Chuck Lever
2020-09-21 18:12 ` [PATCH v2 15/27] NFSD: Add client ID lifetime tracepoints Chuck Lever
2020-09-21 18:12 ` [PATCH v2 16/27] NFSD: Add tracepoints to report NFSv4 session state Chuck Lever
2020-09-21 18:12 ` [PATCH v2 17/27] NFSD: Add a tracepoint to report the current filehandle Chuck Lever
2020-09-21 18:12 ` [PATCH v2 18/27] NFSD: Add GETATTR tracepoint Chuck Lever
2020-09-21 18:12 ` [PATCH v2 19/27] NFSD: Add tracepoint in nfsd4_stateid_preprocess() Chuck Lever
2020-09-21 18:12 ` [PATCH v2 20/27] NFSD: Add tracepoint to report arguments to NFSv4 OPEN Chuck Lever
2020-09-21 18:12 ` [PATCH v2 21/27] NFSD: Add a tracepoint for DELEGRETURN Chuck Lever
2020-09-21 18:12 ` [PATCH v2 22/27] NFSD: Add a lookup tracepoint Chuck Lever
2020-09-21 18:12 ` [PATCH v2 23/27] NFSD: Add lock and locku tracepoints Chuck Lever
2020-09-21 18:12 ` [PATCH v2 24/27] NFSD: Add tracepoints to record the result of TEST_STATEID and FREE_STATEID Chuck Lever
2020-09-21 18:13 ` [PATCH v2 25/27] NFSD: Rename nfsd_ tracepoints to nfsd4_ Chuck Lever
2020-09-21 18:13 ` [PATCH v2 26/27] NFSD: Add tracepoints in the NFS dispatcher Chuck Lever
2020-09-24 23:45 ` J. Bruce Fields
2020-09-25 13:59 ` Chuck Lever
2020-09-25 14:17 ` Bruce Fields
2020-09-25 14:21 ` Chuck Lever
2020-09-25 14:18 ` Chuck Lever
2020-09-25 14:47 ` Bruce Fields
2020-09-21 18:13 ` [PATCH v2 27/27] NFSD: Replace dprintk callsites in fs/nfsd/nfsfh.c Chuck Lever
2020-09-24 21:36 ` [PATCH v2 00/27] NFSD operation monitoring tracepoints J. Bruce Fields
2020-09-25 13:59 ` Chuck Lever
2020-09-25 14:32 ` Bruce Fields
2020-09-25 14:36 ` Chuck Lever
2020-09-25 15:00 ` Bruce Fields
2020-09-25 15:05 ` Chuck Lever
2020-09-25 17:04 ` Chuck Lever [this message]
2020-09-25 18:37 ` Bruce Fields
2020-09-25 18:41 ` Chuck Lever
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=551339D6-2109-487D-8279-746BCA106893@oracle.com \
--to=chuck.lever@oracle.com \
--cc=Bill.Baker@oracle.com \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.