Bug 209420
| Summary: | NFS data corruption | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David Howells <dhowells> | ||||||
| Component: | kernel | Assignee: | Steve Dickson <steved> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 6 | CC: | avi, dwmw2, pb--bugzilla, wtogami | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2006-11-12 05:46:26 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 210071 | ||||||||
| Attachments: |
|
||||||||
Created attachment 137810 [details]
Network trace of echo/od on warthog
Created attachment 138084 [details]
Purposed Upstream Patch
This appears to be fixed in 2.6.18-1.2759.fc6. 2.6.18-1.2759.fc6 also fixes 209977. Thanks! teith:~: echo CBA>tmp/n;od -c tmp/n;ssh -n -x greta echo X\>tmp/n;od -c tmp/n 0000000 C B A \n 0000004 0000000 X \n 0000002 teith:~: uname -a Linux teith.cl.cam.ac.uk 2.6.18-1.2759.fc6 #1 SMP Tue Oct 10 17:34:23 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux teith:~: should be fixed in 2.6.18-1.2849.fc6 now in updates |
I'm seeing the ~/Mail/inbox/.mh_sequences file in my NFS mounted homedir acquiring extra NUL chars on the end. I can reproduce this simply, using two client machines. One of them (warthog, say) uses echo to create a file: echo hello >~/hello Then a second machine (hades) extends it: echo hello >>~/hello Then the first machine looks at it again: od -c <~/hello 0000000 h e l l o \n \0 \0 \0 \0 \0 \0 0000014 Note that the file has been extended by as many NUL characters as were in the original write. I suspect that it will cut off at a page boundary as NFS will be forced to go and fetch a new page at that point. I've attached a wire trace of the first client (warthog) covering the echo/od sequence. Note that though there's a write (packet 14) for the echo on warthog, there's no read to show that the data is being read back. warthog knows the file is bigger - it learnt that in packet 21.