[lkml]   [1999]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: NFS client performance 1.5 orders of magnitude too slow?
    Godmar Back <> writes:

    > So, I guess I have two questions:
    > + Why does Linux do the getattr following the write?

    It shouldn't unless you have turned off attribute caching. If this is
    not the case, please try 'echo 9 >/proc/sys/sunrpc/nfs_debug' and send
    me the syslogged output.

    > + Assuming the write takes so long (almost 5 ms) because the server does
    > synchronous writes to disk, then the issue is that Linux doesn't aggregate
    > write requests?
    > I assume this is what the README file for nfsserver2.2beta40
    > means when it says:
    > * NFS operation between two Linux boxes can be quite
    > slow. There are a number of reasons for this, only one
    > of which is that unfsd runs in user space. Another
    > (and much worse) problem is that the Linux NFS client
    > code currently does no proper caching, read-ahead and
    > write-behind of NFS data. This problem can be helped
    > by increasing the RPC transfer size on the client by
    > adding the `rsize=8192,wsize=8192' mount options. This
    > will at least improve throughput when reading or
    > writing large files. You are still in a lose-lose
    > situation when applications write data line by line or
    > with no output buffering at all.

    Looks like nobody has updated that for a while. Linux-2.2.x has both
    read and write caching. The wsize is limited in stock linux-2.2.x to
    the page size (4k on ix86 machines), but there are currently
    experimental patches for exceeding this value.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:50    [W:0.020 / U:25.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site