[Linux-cluster] GFS lock cache or bug?
jas199931 at yahoo.com
Thu May 8 08:49:05 UTC 2008
I used to 'ls -la' a subdirecotry, which contains more
than 30,000 small files, on a SAN storage long time
ago just once from Node 5, which sits in the cluster
but does nothing. In other words, Node 5 is an idel
Now when I looked at /proc/cluster/dlm_locks on the
node, I realised that there are many PR locks and the
number of PR clocks is pretty much the same as the
number of files in the subdirectory I used to list.
Then I randomly picked up some lock resources and
converted the second part (hex number) of the name of
the lock resources to decimal numbers, which are
simply the inode numbers. Then I searched the
subdirectory and confirmed that these inode numbers
match the files in the subdirectory.
Now, my questions are:
1) how can I find out which unix command requires what
kind of locks? Does the ls command really need PR
2) how long GFS caches the locks?
3) whether we can configure the caching period?
4) if GFS should not cache the lock for so many days,
then does it mean this is a bug?
5) Is that a way to find out which process requires a
particular lock? Below is a typical record in
dlm_locks on Node 5. Is any piece of information
useful for identifing the process?
Resource d95d2ccc (parent 00000000). Name (len=24) "
Local Copy, Master is node 1
137203da PR Master: 73980279
6) If I am sure that no processes or applications are
accessing the subdirectory, then how I can force GFS
release these PR locks so that DLM can release the
corresponding lock resources as well.
Thank you very much for reading the questions and look
forward to hearing from you.
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
More information about the Linux-cluster