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

[EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> 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, [EMAIL PROTECTED] 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
>>> [EMAIL PROTECTED]
>>
>>
>>
>>
>> --
>> Linux-cluster mailing list
>> [email protected]
>> https://www.redhat.com/mailman/listinfo/linux-cluster
>>
>
> --
> Linux-cluster mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/linux-cluster

Attachment: smime.p7s
Description: S/MIME cryptographic signature

--
Linux-cluster mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-cluster

Reply via email to