more weird bugs with mmap-ing via NFS

[Patrick M. Hausen]

Hi!

On Tue, Mar 21, 2006 at 06:26:45PM -0500, Mikhail Teterin wrote:
> The problem is about same with 32K and 16K packets. With 8K packets, the thing 
> kind-of works (although trying to `systat -vm' still stalls disk access), but 
> the outgoing traffic is over 20Mb/s on average -- MUCH more, than the writing 
> program itself generates.

Are you using TCP or UDP for your NFS mounts?

In the latter case, there is a scenario that makes a
"doesn't work optimally" situation become a "doesn't work at all"
situation.

RPC over UDP either completes or doesn't. With 8k packets
every write of a sufficiently large block (>= 8k) will
generate 6 IP fragents that are sent back-to-back as fast as
the sender can.

If the receipient cannot cope with these frames fast enough and
a single frame is lost, then the entire UDP packet is dropped.
This triggers a timeout on the sending side, eventually.
Which causes retransmission of the entire UDP packet, i.e.
the same 6 IP fragments - with the same result: they are
not received entirely -> the packet is dropped again.

This used to be the case 10 years ago with may PC based
NFS clients and network cards that weren't able to receive
6 packets sent back-to-back. Solution: set the read and
write buffer size sufficiently low, as low as 1k in many
situations. The first NE2000 network cards and clones
were famous for this problem.

Now imagine a client that experiences this problem only
sometimes. Modern hardware, but for some reason (network
congestion?) some frames are still lost if sent back-to-back.
(Realtek chipset on the receiving side?)

Of course, if you are using TCP, my entire mail doesn't apply ;-)

HTH,
Patrick
-- 
punkt.de GmbH         Internet - Dienstleistungen - Beratung
Vorholzstr. 25        Tel. 0721 9109 -0 Fax: -100
76137 Karlsruhe       http://punkt.de