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.
Attachments
Issue Links
Activity
| Fix Version/s | New: Lustre 2.10.0 [ 12204 ] | |
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: In Progress [ 3 ] | New: Resolved [ 5 ] |
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/14961/
Subject: LU-6648 wireshark: Process ldlm intent getxattr
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: c252b3b1658cb9615989aae333ab8157e8386c4f
| Labels | New: wireshark |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Nathaniel Clark (nathaniel.l.clark@intel.com) uploaded a new patch: http://review.whamcloud.com/14961
Subject: LU-6648 wireshark: Process ldlm intent getxattr
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 3a8324f9fed91d677a7751add5574bd8b66bcc73
| Description |
Original:
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_. 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. |
New:
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. |
| Attachment | New: 2015-05-26_14-55-43_c20.tcpdump [ 17968 ] |
Landed for 2.10