Re: "server wrote less than expected" - NFS

This is a discussion on Re: "server wrote less than expected" - NFS ; Interesting twist to this ... try to copy a file to another file such as: cp file1 file2 .... and the command always fails the first time, though some data is likely written to file2 (but file2 is smaller than ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: "server wrote less than expected"

  1. Re: "server wrote less than expected"

    Interesting twist to this ... try to copy a file to another file such as:

    cp file1 file2

    .... and the command always fails the first time, though some data is
    likely written to file2 (but file2 is smaller than file1 after completion).

    Try the command again right away -- even if you delete the
    originally-created file2 first, and the command succeeds perfectly!

    Very strange behavior indeed. Any ideas? TIA.

    baker@deslab.MIT.edu


    Mike Eisler wrote:
    > "F. Baker" wrote in message news:<40575ba8$0$563$b45e6eb0@senator-bedfellow.mit.edu>...
    >
    >>We have several Mandrake 9.2 x86 workstations here. In "dmesg" on
    >>these PCs I see a lot of errors that read:
    >>
    >>eth0: TX underrun, threshold adjusted.
    >>
    >> AND
    >>
    >>NFS: Server wrote less than requested.
    >>
    >>This message appears whenever someone logged into the Mandrake box
    >>(with NFS autofs mounting in his/her home directory) tries to write
    >>something to an nfs-mounted directory (usually the home directory).
    >>Even small files of 1.5 MB or so often generate something such
    >>as "I/O error" when saving a file (really small files usually
    >>get saved fine). And the home directory is always based in an
    >>SGI (O2, Indy, Onyx) with xfs file system. Intra-SGI these transfers
    >>take place perfectly, but Mandrake (as was the case when we had RedHat
    >>as well) generates these problems.

    >
    >
    > I've seen this with Linux clients before, and the observed caused was
    > an NFS server that has a tunable maximum transfer size for WRITE
    > procedures, and someone has lowered this value to below what it was
    > when the client mounted the NFS filesystem. If so, remounting
    > should fix it.
    >
    >>Has anyone seen this error before and does anyone know how
    >>to get around it? The kernel used is 2.4.22-28 for most
    >>of the Mandrake boxes, or at least 2.4.x anyway.
    >>
    >>Thanks in advance.
    >>
    >>baker@deslab.mit.edu



  2. Re: "server wrote less than expected"

    On 2004-04-01 17:52, F. Baker wrote:
    > Interesting twist to this ... try to copy a file to another file such as:
    >
    > cp file1 file2
    >
    > ... and the command always fails the first time, though some data is
    > likely written to file2 (but file2 is smaller than file1 after completion).
    >
    > Try the command again right away -- even if you delete the
    > originally-created file2 first, and the command succeeds perfectly!
    >
    > Very strange behavior indeed. Any ideas? TIA.
    >
    > baker@deslab.MIT.edu
    >
    >
    > Mike Eisler wrote:
    >
    >> "F. Baker" wrote in message
    >> news:<40575ba8$0$563$b45e6eb0@senator-bedfellow.mit.edu>...
    >>
    >>> We have several Mandrake 9.2 x86 workstations here. In "dmesg" on
    >>> these PCs I see a lot of errors that read:
    >>>
    >>> eth0: TX underrun, threshold adjusted.
    >>>
    >>> AND
    >>>
    >>> NFS: Server wrote less than requested.
    >>>
    >>> This message appears whenever someone logged into the Mandrake box
    >>> (with NFS autofs mounting in his/her home directory) tries to write
    >>> something to an nfs-mounted directory (usually the home directory).
    >>> Even small files of 1.5 MB or so often generate something such
    >>> as "I/O error" when saving a file (really small files usually
    >>> get saved fine). And the home directory is always based in an
    >>> SGI (O2, Indy, Onyx) with xfs file system. Intra-SGI these transfers
    >>> take place perfectly, but Mandrake (as was the case when we had RedHat
    >>> as well) generates these problems.

    >>
    >>
    >>
    >> I've seen this with Linux clients before, and the observed caused was
    >> an NFS server that has a tunable maximum transfer size for WRITE
    >> procedures, and someone has lowered this value to below what it was
    >> when the client mounted the NFS filesystem. If so, remounting
    >> should fix it.
    >>
    >>> Has anyone seen this error before and does anyone know how
    >>> to get around it? The kernel used is 2.4.22-28 for most
    >>> of the Mandrake boxes, or at least 2.4.x anyway.
    >>>
    >>> Thanks in advance.
    >>>
    >>> baker@deslab.mit.edu

    >
    >



    Try to add the mount option tcp in auto.master

    example:
    /home auto.home -rw,nobrowse,tcp,rsize=8192,wsize=8192

    We had a problem when the copy of a 54MB file just hang after 37797888 bytes every time.
    (Copy from Solaris to Linux nfs)
    I don't know if Linux will try udp as default or not, but it did use udp in some cases,
    and we got strange network errors. (

    The tcp option solved our problems.


    /bb



  3. Re: "server wrote less than expected"

    I am having the exact same problem on a RHAT9.0 SMP box. I have two
    network cards installed SMC 1000BT (sk98lin) and intel Pro100 (e100)
    and the error is appearing on both cards. It is happening over any
    SGI NFS mount (connecting to SGI Onyx/Origin2000).

    Oddly, I can transfer data without error from the machine, though
    shell scripts fail when data intensive applications (neuroimaging
    apps) try to pull from NFS stores.

    I receive the same error as F. Baker in /var/log/messages after a
    failure.

    Any help is appreciated!

    --KM

    "F. Baker" wrote in message news:<406c3aaa$0$574$b45e6eb0@senator-bedfellow.mit.edu>...
    > Interesting twist to this ... try to copy a file to another file such as:
    >
    > cp file1 file2
    >
    > ... and the command always fails the first time, though some data is
    > likely written to file2 (but file2 is smaller than file1 after completion).
    >
    > Try the command again right away -- even if you delete the
    > originally-created file2 first, and the command succeeds perfectly!
    >
    > Very strange behavior indeed. Any ideas? TIA.
    >
    > baker@deslab.MIT.edu
    >
    >
    > Mike Eisler wrote:
    > > "F. Baker" wrote in message news:<40575ba8$0$563$b45e6eb0@senator-bedfellow.mit.edu>...
    > >
    > >>We have several Mandrake 9.2 x86 workstations here. In "dmesg" on
    > >>these PCs I see a lot of errors that read:
    > >>
    > >>eth0: TX underrun, threshold adjusted.
    > >>
    > >> AND
    > >>
    > >>NFS: Server wrote less than requested.
    > >>
    > >>This message appears whenever someone logged into the Mandrake box
    > >>(with NFS autofs mounting in his/her home directory) tries to write
    > >>something to an nfs-mounted directory (usually the home directory).
    > >>Even small files of 1.5 MB or so often generate something such
    > >>as "I/O error" when saving a file (really small files usually
    > >>get saved fine). And the home directory is always based in an
    > >>SGI (O2, Indy, Onyx) with xfs file system. Intra-SGI these transfers
    > >>take place perfectly, but Mandrake (as was the case when we had RedHat
    > >>as well) generates these problems.

    > >
    > >
    > > I've seen this with Linux clients before, and the observed caused was
    > > an NFS server that has a tunable maximum transfer size for WRITE
    > > procedures, and someone has lowered this value to below what it was
    > > when the client mounted the NFS filesystem. If so, remounting
    > > should fix it.
    > >
    > >>Has anyone seen this error before and does anyone know how
    > >>to get around it? The kernel used is 2.4.22-28 for most
    > >>of the Mandrake boxes, or at least 2.4.x anyway.
    > >>
    > >>Thanks in advance.
    > >>
    > >>baker@deslab.mit.edu


+ Reply to Thread