Description of problem: In order to match up file system and lock space, could the mount option "id=" in /proc/mounts be printed in hex instead if decimal? This would make it easier to match the lockspace against the output of group_tool. [root@morph-03 ~]# group_tool type level name id state fence 0 default 00010001 none [1 2 3 4] dlm 1 clvmd 00030001 none [1 2 3 4] dlm 1 morph-cluster0 00050001 none [1 2 3 4] gfs 2 morph-cluster0 00040001 none [1 2 3 4] Actual results: /dev/mapper/morph--cluster-morph--cluster0 on /mnt/morph-cluster0 type gfs (rw,hostdata=jid=2:id=262145:first=0,oopses_ok,debug) Expected results: /dev/mapper/morph--cluster-morph--cluster0 on /mnt/morph-cluster0 type gfs (rw,hostdata=jid=2:id=00040001:first=0,oopses_ok,debug) Additional info:
I think this may be a simple change to the gfs_controld group daemon, specifically, recover.c. Adding Dave Teigland to the cc list since he wrote it and may have something to add.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
The problem with that is it's a part of the kernel abi. See linux/fs/gfs2/locking/dlm/mount.c:make_args() Also, it's not the dlm lockspace you're matching with there, it's the gfs mountgroup. This is the lockspace: dlm 1 morph-cluster0 00050001 none This is the corresponding mountgroup: gfs 2 morph-cluster0 00040001 none which I think is what you want to match with id=262145(40001) in /proc/mounts. (In general it's best to use the name to find the associations, but I realize that involves even more complexity digging around in sysfs.)
Due to the kernel abi issues, the executive decision was made not to fix this.