Bug 16911
Summary: | Data corruption due to race between rpc-resend of O_DIRECT WRITE and server OK response. | ||
---|---|---|---|
Product: | File System | Reporter: | Fred Isaman (iisaman) |
Component: | NFS | Assignee: | Trond Myklebust (trondmy) |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | alan, bfields |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | Subsystem: | ||
Regression: | No | Bisected commit-id: | |
Attachments: |
Trace immediately before connection loss
Trace immediately after connection loss |
Description
Fred Isaman
2010-08-24 14:54:05 UTC
Created attachment 27811 [details]
Trace immediately before connection loss
Client is in the middle of a write, several WRITEs are outstanding without reply from server when connection is lost
What should the server be doing? (I can't get wireshark to parse that trace for me, by the way.) Created attachment 27821 [details]
Trace immediately after connection loss
Server immediately sends back (unsolicited) OK to all outstanding WRITEs. The client soon sends a corrupted RPC replay of one of the outstanding WRITEs (xid=15..., but with data from a future WRITE xid=28). The client then starts another corrupted RPC replay of a WRITE (xid=22, data from future WRITE xid=29), but the connection is broken again before that is completely sent.
(In reply to comment #2) > What should the server be doing? > > (I can't get wireshark to parse that trace for me, by the way.) The server should wait for the client to send the replay, and reply to that. (Note the trace is the linux client, but not the linux server.) Regarding parsing, I also find it does not parse unless I go into the wireshark menu Analyze->"decode as" and change DCE-RPC to RPC. I am not sure why that is necessary. |