[Linux-cluster] GFS lock cache or bug?

Wendy Cheng s.wendy.cheng at gmail.com
Thu May 8 13:28:22 UTC 2008

Ja S wrote:
> Hi, All:

I have an old write-up about GFS lock cache issues. Shareroot people had 
pulled it into their web site:

It should explain some of your confusions. The tunables described in 
that write-up are formally included into RHEL 5.1 and RHEL 4.6 right now 
(so no need to ask for private patches).

There is a long story about GFS(1)'s "ls -la" problem that one time I 
did plan to do something about it. Unfortunately I'm having a new job 
now so the better bet is probably going for GFS2.

Will pass some thoughts about GFS1's "ls -la" when I have some spare 
time next week.

-- Wendy

> 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
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster

More information about the Linux-cluster mailing list