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 <yvette@xxxxxxxxxxxx> wrote:
Digimer wrote: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.
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.
see here: http://lwn.net/Articles/245002/
the article didn't specify the filesystem...
yvette
--
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