Bug 427386 – RFE: print mount option id= in hex

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 427386 - RFE: print mount option id= in hex

Summary:	RFE: print mount option id= in hex

Status:	CLOSED WONTFIX

Aliases:	None

Product:	Red Hat Enterprise Linux 5
Classification:	Red Hat
Component:	cman (Show other bugs)
Sub Component:
Version:	5.2
Hardware:	All Linux

Priority	low Severity low
Target Milestone:	rc
Target Release:	---
Assigned To:	Robert Peterson
QA Contact:	GFS Bugs
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2008-01-03 12:19 EST by Nate Straz
Modified:	2009-04-16 19:00 EDT (History)
CC List:	2 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2008-01-08 13:19:02 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Nate Straz 2008-01-03 12:19:47 EST

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:

Comment 1 Robert Peterson 2008-01-03 13:11:37 EST

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.

Comment 2 RHEL Product and Program Management 2008-01-03 13:14:29 EST

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.

Comment 3 David Teigland 2008-01-03 13:35:26 EST

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.)

Comment 4 Robert Peterson 2008-01-08 13:19:02 EST

Due to the kernel abi issues, the executive decision was made not to
fix this.

Note You need to log in before you can comment on or make changes to this bug.