[Linux-cluster] GFS lock cache or bug?

[Ja S]

Hi, All:

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
node.

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
lock? 

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) "  
    5          cb5d35"
Local Copy, Master is node 1
Granted Queue
137203da PR Master:     73980279
Conversion Queue
Waiting Queue


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.

Jas


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ