hi all,
i've been seeing some performance problems with openbsd 4.5 as nfs client.
i've now installed current and the symptoms persist:
1. the attributes returned in readdirplus by the server are not
used. e.g. for an "ls -l" on an nfs directory, openbsd will do a
"readdirplus" transaction, followed by a "lookup" for each file.
the lookups are superfluous most of the time.
the "cache_purge" of the directory(!) vnode before the "nfs_cache_enter"
in "nfs_readdirplusrpc" may be the problem. removing it does make
the lookups go away, but perhaps something else has to be flushed
there...
2. flushing buffers to disk can cause unnecessary FILESYNC writes.
nfs_flush executes commit nfs transactions, but only for 20 blocks
at a time. in practice (as seen in protocol transcripts), nfs_flush
does two nfs commits, then flushes remaining dirty blocks by
FILESYNC-writing them. the limit is supposedly low (20) because it
needs memory on the stack (or otherwise malloc, which can fail and
needs more code to handle (freebsd seems to do this)). perhaps the
first pass (where an nfs commit request is sent) can be done
more often? i.e. continue doing commits until there are no more
blocks to commit by nfs commit request. i've tested this initially
against an openbsd 4.5 server and linux in-kernel server, now with
openbsd current as client only against the linux in-kernel server.
i can reproduce it by:
"dd if=/dev/zero of=/mnt/nfs/somefile bs=8192 count=48"
i suspect any count >2*20 shows the behaviour.
the protocol transcript shows a series of writes, followed by two
commits: first for the last 20 blocks, then for the last 40 blocks
(apparently taking into account the last 20 were already committed),
followed by separate FILESYNC-writes for the remaining leading 8
blocks (which had already been written).
i don't know enough of the code (including vnodes in general) to propose
a patch, sorry.
mjl
