Bug 3758
Summary: | nfs client write bug | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | brm |
Component: | kernel | Assignee: | David Lawrence <dkl> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.0 | CC: | brm, brownb, dautrevaux |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 1999-06-28 13:24:34 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: |
Description
brm
1999-06-27 06:35:20 UTC
This is a known bug in Solaris. You need to get the Solaris Errata or move to Solaris 2.6 or higher. The sun patches should be on sunsolve. The report you have is the classic offset by 1-3 bytes problem that is the clear evidence of the bug. Discarding bug as it is actually known problem with Solaris and not problem with Red Hat Linux. *** Bug 3807 has been marked as a duplicate of this bug. *** When using Red Hat Linux 6.0 as an NFS client to a host running Solaris 2.5.1, I've seen file corruption. The specific trigger is running ld to link executables -- the output file is messed up with some regularity. I do not know which side of the NFS connection is to blame. It could be a bug in the Solaris server. I have not yet seen the problem with servers running Solaris 2.6. When I look at the bytes that are wrong it looks like some byte or word swapping has occurred. Here is some output of "cmp -l" showing some of the differences between a good file and a corrupted one: 36525 33 0 36527 0 33 36529 1 0 36531 0 1 36533 6 0 36535 0 6 36541 100 0 36543 0 100 36545 140 0 36546 42 0 36547 0 140 36548 0 42 36557 20 0 36559 0 20 36565 41 0 36567 0 41 36569 11 0 36571 0 11 36581 314 0 36582 224 0 36583 0 314 36584 0 224 36585 260 0 36586 23 0 36587 0 260 36588 0 23 36589 14 0 36591 0 14 36593 1 0 36595 0 1 36597 4 0 36599 0 4 36601 10 0 36603 0 10 36605 53 0 36607 0 53 ------- Additional Comments From 06/29/99 12:36 ------- We have a large amount of experience with Red Hat 5.1 and the bug was definitely not present in that release. It only appeared after the 6.0 upgrade. I'm using RedHat-6.1 kernel and I have exactly the same kind of NFS bug, with file systems mounted from a Solaris-2.6 PC; I've have it occasionnaly on gcc compiles (as I usually compile to the local disk) but have it also on some of my programs that write through NFS. After some head scratching I discover it was linked with using fseek on an NFS mounted file, where when seeking at say offset 8000 from the beginning of the file and writing 2000 bytes (in a signed fwrite), I get one zero (but may be up to three zeroes) inserted at 1000, then the first 191 bytes I wrote (see the pattern: up to byte 8191) then the 192nd byte is omitted and the rest of my write gets out correctly. Suspecting a possible problem with stdio, I added a flush, then an fseek in 0 followed by a small fread there, then the correct fseek in 8000. if I then wrote less than 193 bytes everything is OK; but if I write 2000 bytes, the byte that should be written at offset 8192 is missing (IIRC) and the others are shifted :-< To work around this I finally have to fclose() the file and the fopen() it again, always in binary mode but for update... then all seems to work OK for more than one month now (although gcc compiles still fail occasionally). The main point here is that I get these problem with several kernels (stock 6.0, stock 6.1, stock 6.1smp and 2.2.14-8smp) mounting an NFS file system from a Solaris-2.6 PC, that work perfectly with RedHat-4.0, RedHat-5.2, hpUX-9.07, hpUX-10.20, Solaris-2.5 (Sparc) and AIX-4.2... Even if its a problem with Solaris, it's a pity that all the proprietary OSes are able to work OK but not Linux!... |