[Linux-cluster] GFS2/DLM deadlock

[Henderson, Jason]

On Mon, Sep 10, 2012 at 8:21 AM, Bob Peterson <rpeterso at redhat.com> 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.