On Thu, Jun 09, 2005 at 10:29:08AM -0500, Andrew C. Dingman wrote: > My thinking when I wrote that question was a little sloppy, and the > particular lock calls I mentioned aren't actually relevant to what I > meant. Sorry. > > What I mean is that presumably most locks GFS takes out correspond to > activity of a client process that needs to read or write the blocks > covered by that lock. It therefore seems like it ought to be possible to > determine which file the locked area belongs to, and then which process > on the machine holding the lock is responsible for the activity which > necessitated GFS taking out the lock. > > Am I making any more sense? much clearer. and yes, you can do that. ok. gfs grabs locks based on inodes numbers. So, if you wanted, you could poke around in proc, and figure out with files a process had, then poke at the fs to see what the inodes for those files are. Then (in the case for gulm) dump the lockspace, decode that, and look for the inodes. (which I think are shifted by 8 bits.) Or any arangment of those steps to find out which bits you wanted to know. That does assume that things are accessable enough that you can access the filesystem to get that info. -- Michael Conrad Tadpol Tilstra You are not your body.
Attachment:
pgpx2soFnJC38.pgp
Description: PGP signature
-- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
