It really depends on what you are doing.
GFS, in it's current state, favors large I/O. You can get very good results if separate machines are simultaneously doing large block I/O.
For now, think of it like this: 1) the larger the block I/O, the better the performance 2) simultaneous non-contending I/O from different machines increase throughput.
You are probably testing from one machine with smaller I/O - violating both 1 & 2 above. In which case, ext3 - a file system designed to be local (as opposed to clustered) - should be faster.
That being said, there are a number of improvements coming in GFS that will greatly improve workloads like the one you are testing.
Also, there are HA advantages to consider. Performance vs High Availability... Hopefully, in the not to distant future, you will not have to choose, but will get both from GFS.
brassow
One way to think about the current state of GFS is to compare it to thread programming. If you add threading to your program, but it has to do alot of locking and only runs on one processor; you've just killed all your performance. If you add a processor (or machines in GFS's case), it is possible that you will see speedup. If you increase your work chunks (increase I/O size) and reduces locking (reduce contention), you will see great improvements.
On Apr 27, 2005, at 8:53 AM, Patricio Bruna V. wrote:
Its normal that GFS goes slower than ext3? i have the following scenario:
2 Dell 2.4G Xeon (dual) 2 HBA each 1 500GB Storage.
i have configured GFS 6 and make some test on it and ext3 its far faster.
--
Patricio Bruna
pbruna@xxxxxxxxxxxxxxxxx
RHCE/RHCI
Jefe Soporte y Operaciones LinuxCenter S.A.
Canada 239, 5to piso, Providencia, Chile
http://www.linuxcenterla.com +56-2-2745000
--
Linux-cluster@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/linux-cluster
-- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
