On Mon, Sep 10, 2012 at 8:21 AM, Bob Peterson <rpeterso@xxxxxxxxxx> wrote: > > ----- Original Message ----- > | I'm not clear on the two different inode numbers in the two lines > | above: > | Which n: number do I use to locate the file the lock is for? The one > | in the > | glock line or the one in the I: line? From RedHat docs I have read, I > | should convert the 81523 (from the '2/ 81523') to decimal, which is > | 533795, > | and then use 'find -inum 533795' to locate the file after the > | filesystem > | has been unfrozen. > | > | I guess my confusion is the definition of a "disk inode's block > | address" > | versus an "inode disk address". Could you clarify the difference for > | me? > > Hi, > > Technically, there are two inode numbers in GFS2: The "formal inode > number" > and the "block number" or "block address". You need only ever concern > yourself with the latter. The first number is not used for anything > (except possibly in NFS situations). In your example, the device block > address is 0x81523, which is 529699 (not 533795 which is 0x82523) decimal. > This is the value that "stat <file>" will return as "Inode:", and it's the > same value that is used by "find -inum <X>". Because we don't typically > use or care about the first number, we often use the terms "block address" > and "inode number" interchangeably, since really they're the same thing > in GFS2. > Thanks for the explanation and apologies for my bonehead math error. Not sure why I was converting the wrong hex number. I guess I shouldn't work on the weekends. :-) I will report back the call trace of the hung process when we reproduce the issue. -- This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message. -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
