NFS client behavior on close

[Simon Kirby]

'lo,

I have a simple script which downloads pictures from my camera's flash
card and writes them to the current directory, which is often on an NFS
mount to a box with available HD space.

I noticed that with files of about this size (~5 MB), there seems to be a
lot of blocking with "cp" (or "mv"), noted by the LED on the card reader
being idle between each file.  What seems to be happening is that "cp"
will open() the source and destination, read and write a bunch of times,
and then close() the destination and source.  An "strace -r" reveals that
on the close() of the destination, "cp" blocks for quite a while. 
Looking at the network, it appears this is happening:

- cp starts copying, data goes to dirty cache (not yet to NFS server)
- cp closes destination
- cp blocks while NFS client writes dirty cache to NFS server
- cp wakes back up when NFS has written all data
- cp proceeds to the next file

This is quite suboptimal in that while the file is being read from the
(relatively slow) compact flash reader it has not yet started writing
over the network, and then between each file it writes all data.

Is the NFS client required to write all data on close?  If I mount with
"noac", downloads are actually faster because each block is written
immediately and there's nothing to unclog on close().  However, with this
option all other bulk transfers are slower (the network never saturates).

I'm using NFSv3.  Would NFSv4 or another version behave differently here?

2.6.6 server and client, btw.  Server exported "async", though exported
with "sync" appears equivalent to the client.

...
     0.000073 read(3, "\f\0\322\0z\0\200\0\r\0\n\0"..., 4096) = 800
     0.000065 write(4, "\f\0\322\0z\0\200\0\r\0\n\0"..., 800) = 800
     0.000066 read(3, "", 4096)         = 0
     0.000055 close(4)                  = 0
     0.906548 close(3)                  = 0

Thanks,

Simon-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/