[Linux-cluster] GFS Performance

[Ken Preslan]

It's not the directory that that's causing the slowness, but the fact
that the "ls -la" tries to a stat() on the file that's being written
to by node 1.  Node 1 has to sync out all the dirty data in its cache
before it can release the lock to node 2.  This can take a while if Node
1 has a big (and full) cache.

You can do a ls without the -l option, so it won't stat() the files in
the directory.  That should be faster.

The ultimate solution is to add buffer forwarding to GFS, so node 1 can
give node 2 stat() information without having to flush all its data.
But that's a ways off.


On Thu, Jul 08, 2004 at 02:27:38PM +0200, Richard Mayhew wrote:
> Hi
> 
> 
> I setup 2 nodes, on my EMC SAN. Both nodes see the storage and can
> access the cca device.
> When writing a file to the storage fs, the second node takes a couple of
> seconds to see the changes.
> 
> Ie. 
> 1. Node 1 Creates the file "dd if=/dev/zero of=test.file bs=4096
> count=10240000"
> 2. Doing a ls -la on node 2 takes a few seconds to display the contents
> of the dir.
> 
> After the file has finished being updates, all listings of that dir are
> quick, but if any changes are made, one again has to wait for the system
> to display the contents of the dir.
> 
> Any idea?
> 
> 
> 
> --
> 
> Regards
> 
> Richard Mayhew
> Unix Specialist
> 
> MWEB Business
> Tel:  + 27 11 340 7200
> Fax:  + 27 11 340 7288
> Website: www.mwebbusiness.co.za
> 
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-cluster

-- 
Ken Preslan <kpreslan at redhat.com>