Details
-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
3
-
9223372036854775807
Description
Running the experiment 'multiop <file> Oac' to generate a getxattr VFS method call results in a tcpdump trace that the Lustre Wireshark extension fails to parse correctly.
wireshark-1.8.10 was used built against a fairly recent checkout of Lustre HEAD (as of May 26, 2015). The tcpdump file it failed to parse is attached. Look for the "LDLM_ENQUEUE request [Protected Read][ intent : getxattr ]" and its reply. The tcpdump itself is taken from the client that ran the 'mulitop' command.
A followup experiment that does the complimentary 'setxattr' ('multiop <file> OAc') also shows a LustreBUG in the summary output for the client that does the operation (2015-05-26_14-55-43_c20.tcpdump). When I look at the detailed output for both of these ('tshark -v ...') neither of them shows the LustreBUG output from the summary view. Not sure if that means it's just a reporting problem or a real failure to parse.
For the 'getxattr' experiment the header says there are four buffers with non-zero length, but only three get displayed:
Lm Buflens: 184 => ptlrpc_body
Lm Buflens: 104 => ldlm_request
Lm Buflens: 8 => intent opcode
Lm Buflens: 216 => nothing
Lm Buflens: 0
For the 'setxattr' case thingsare a litle different:
Lm Buflens: 184 => ptlrpc_body
Lm Buflens: 136 => mdt_rec_reint
Lm Buflens: 0
Lm Buflens: 13 => "user.multiop"
<extra padding>
Lm Buflens: 8 => "mds xattr eadata"
Lm Buflens: 104 => llog_cookie
The "mds xattr eadata" is not interpreted. I'd be interested to know if there's anything in there I should know about.