[Linux-cluster] noatime

[Brian Kroth]

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 at bobich.net <gordan at bobich.net>:
> 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 at logicore.net 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 at mhicc.org
>>
>>
>>
>>
>> --
>> Linux-cluster mailing list
>> Linux-cluster at redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-cluster
>>
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2192 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20080129/8ff7a2db/attachment.bin>