[Beowulf] NFS share - IO rate

[Henning Fehrmann]

On Thu, Apr 22, 2010 at 03:32:28PM +0200, Bogdan Costescu wrote:
> On Wed, Apr 21, 2010 at 3:16 PM, Henning Fehrmann
> <henning.fehrmann at aei.mpg.de> wrote:
> > Doing these tests on clients might give a better picture of the
> > usability of the cache system.
> > Measuring the performance on the server wouldn't also take into account the
> > buffering of the VFS or NFS on the client side.
> 
> From what I understand, allowing clients to cache would actually
> reduce the rates that the server has to deal with. If you just want to
> measure the server's response, you could mount the NFS shares with the
> "sync" flag, so that no caching occurs on the clients.

This is correct. Actually, with the async option one gets also a good
overview about buffer sizes. The IO performance drops with increasing file size.

> Another idea: you could measure the network rates on the server; this
> would still include the client caching effects - however this would
> not be very easy to translate into IOP/s.
> 
> > In the bidding process we specified the read and write rate doing random seeks on the server,
> > induced and seen by many clients in parallel.
> 
> OK :-) This still doesn't mention where there measurement takes place...
> 

We really want to measure the IO on the client side, since this is what
matters for the applications. We assume that many clients do
unpredictable seeks in files on the NFS-share for an unknown long run
time. This is what we try to simulate. 

Of course we try to measure consistent results also on the server side. 

I wrote a little program which is doing random seeks, writes or reads
one byte and does a fsync. It starts at a particular system time, runs for
a well defined time and counts the IO. In this way I hope to synchronize the 
tests on the clients, similar as it would be done using MPI synchronized IO tests.
The fsync in fact should prevent the usage of the buffer on the client side. 
We'll see.

Cheers,
Henning