We found with GFS2 on RHEL5.3 the same issue, and although we did not resolve it (and are migrating to NFS+SAN instead), we were able to partially mitigate it with several suggestions from either RedHat's support or from the cluster list: 1. disable LS color output (<a href="http://kbase.redhat.com/faq/docs/DOC-6533">http://kbase.redhat.com/faq/docs/DOC-6533</a>) 2. the "nodiratime,noatime" mount flags 3. Unlocking the plock rate to allow maximum locks generated and purged per second with the "plock_rate_limit=0" option in cluster.conf That said though, we found that the GFS2 was only about as fast as NFS4 on GigE networks, and not the best solution for our setup. <div class="gmail_quote">On Wed, Jul 8, 2009 at 4:58 PM, Peter Schobel <<a href="mailto:pschobel@1iopen.net">pschobel@1iopen.net</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I am trying to set up a four node cluster but am getting very poor performance when removing large directories. A directory approximately 1.6G in size takes around 5 mins to remove from the gfs2 filesystem but removes in around 10 seconds from the local disk. I am using CentOS 5.3 with kernel 2.6.18-128.1.16.el5PAE. The filesystem was formatted in the following manner: mkfs.gfs2 -t wtl_build:dev_home00 -p lock_dlm -j 10 /dev/mapper/VolGroupGFS-LogVolDevHome00 and is being mounted with the following options: _netdev,noatime,defaults. If anyone knows what could be causing this please let me know. I'm happy to provide any other information. Regards, -- Peter Schobel ~ -- Linux-cluster mailing list <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/linux-cluster" target="_blank">https://www.redhat.com/mailman/listinfo/linux-cluster</a> </blockquote></div>