Hi Digimer and Yvette,

Thanks for tips! I don't doubt reliability of the technology, just want to
make sure it is configured well.

After fencing a node that held a lock on a file on shared storage, lock
remains, and non-fenced node cannot take over the lock on that file.
Wondering how can one check which process (from which node if possible) is
holding a lock on a file on shared storage.
dlm should have taken care of releasing the lock once node got fenced,
right?

Regards,
Stevo.

On Fri, Dec 30, 2011 at 8:30 PM, yvette hirth <[email protected]> wrote:

> Digimer wrote:
>
>  For GFS2, one of the easiest performance wins is to set
>> 'noatime,nodiratime' in the mount options to avoid requiring locks to
>> update the access times on files when you only read them.
>>
>
> i've found that "noatime" implies "nodiratime", so both are not needed -
> unless GFS/GFS2 behaves differently than other fs's wrt this attribute.  if
> so, that would be good to know for certain.
>
> see here:  http://lwn.net/Articles/**245002/<http://lwn.net/Articles/245002/>
>
> the article didn't specify the filesystem...
>
> yvette
>
> --
> Linux-cluster mailing list
> [email protected]
> https://www.redhat.com/**mailman/listinfo/linux-cluster<https://www.redhat.com/mailman/listinfo/linux-cluster>
>
--
Linux-cluster mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-cluster

Reply via email to