[linux-cifs-client] Re: What is GetXid/FreeXid supposed to actually do?

[Steve French]

On Sun, May 24, 2009 at 4:03 PM, Jeff Layton <jlayton at redhat.com> wrote:
> On Sun, 24 May 2009 15:38:22 -0500
> Steve French <smfrench at gmail.com> wrote:
>
>> On Sun, May 24, 2009 at 2:31 PM, Christoph Hellwig <hch at infradead.org> wrote:
>> > On Sun, May 24, 2009 at 03:21:07PM -0400, Jeff Layton wrote:
>> >> Any objection to just replacing this xid value with the pid or tgid
>> >> instead? Does this xid value give you anything that that doesn't?
>> >
>> > Yeah, from all that I can see there is always at most one xid in
>> > use per thread.  So just replacing it with a tgid should work easily.
>> > Even better would be replacing all that ad-hoc debugging with the
>> > ftrace event tracer.
>>
>> That may work (using the tgid) but there are various cases where it was
>> helpful to distinguish log entries this way (rather than simply using
>> timestamps,
>> especially since dmesg is lossy so you don't always see the function entry
>> and exits) when you have multiple requests in a series from one or more threads
>> request from thread1, request from thread 2, request 2 from thread1,
>> request 2 from thread 2 etc.
>>
>
> dmesg is never lossy...maybe you mean syslog?

Yes - in particular running dbench with logging on you tend to lose
a lot, and when I add in debugging messages (using the xid)
it helps sort them.

> Anyway, there are never multiple requests in flight from single threads
> in cifs. In all cases, a thread transmits a request and then goes to
> sleep until the reply comes in.

There are a couple of rare cases, but usually this (xid) is to untangle
the case of lots of requests in the log.

> AFAICT too, this xid only ever shows up in one cERROR message:
>
>    cERROR(1, ("Frame too large received.  Length: %d  Xid: %d",
>                receive_len, xid));
>
> ...that just doesn't seem like it's worth the cost.

In the past I also have used it (xid) a lot in debugging through /proc/fs/cifs/

>
>> Using the ftrace event tracer may be good enough for some of this
>> (except the stats gathering, counters) - any pointers to its
>> use in NFS?
>>
>
> I know Steve D. has been working on tracepoints for nfs, but I haven't
> given them a hard look as of yet.

Some guys (OLS speakers) from India were talking about fs tracepoints last
year at OLS but I got the feeling that not much progress had been made.




-- 
Thanks,

Steve