Have a look at this link, it looks related: http://sources.redhat.com/cluster/faq.html#gfs_speed1 http://sources.redhat.com/cluster/faq.html#gfs_slowaftermount As I understand it, basically the first node to access a file must do some lock checks - see if anyone has already locked it, attempt to lock it, let the other nodes know about it, etc. After this, the lock should be cached for a period. There are some tips about that here: http://sources.redhat.com/cluster/faq.html#gfs_tuning I personally, have some nagios/heartbeat checks setup that, among other things, touch a file on the GFS mount (.${HOSTNAME}-check), just to make sure it's still alive, else warn me that I need to poke it. I'm not positive, but I have a feeling that this keeps things "fresh". Perhaps it will help your problem as well. Brian gordan@xxxxxxxxxx <gordan@xxxxxxxxxx>: > The main reason why performance improves with noatime (is the nodiratime > flag supported?) is because it means no write happens for ever file read. > That means no locking required, which is the main thing that slows down > concurrent accesses. I don't know what the first-access issue might be, but > noatime should help under heavy concurrent use. > > Gordan > > On Tue, 29 Jan 2008, isplist@xxxxxxxxxxxx wrote: > >> Were you trying this for a specific reason? I tried noatime to see if I >> could >> get a faster initial response time from the GFS volume. Every time I >> access >> it, there is a long delay initially, then things are fine until the next >> access. >> >> >> On Tue, 29 Jan 2008 09:26:19 -0500, Alexandre Racine wrote: >>> Hi all, >>> >>> If I put in my fstab file: >>> /dev/sdc5 /home gfs noatime >>> >>> >>> Will it actually mount without atime? And how can I confirm this? >>> >>> Thanks. >>> >>> >>> Alexandre Racine >>> 514-461-1300 poste 3304 >>> alexandre.racine@xxxxxxxxx >> >> >> >> >> -- >> Linux-cluster mailing list >> Linux-cluster@xxxxxxxxxx >> https://www.redhat.com/mailman/listinfo/linux-cluster >> > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
-- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
