Bug 435917 - GFS2: mkfs.gfs2 default lock protocol differs from man page
Summary: GFS2: mkfs.gfs2 default lock protocol differs from man page
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs2-utils   
(Show other bugs)
Version: 5.2
Hardware: All Linux
Target Milestone: rc
: ---
Assignee: Robert Peterson
QA Contact: GFS Bugs
Depends On: 311591
TreeView+ depends on / blocked
Reported: 2008-03-04 13:34 UTC by Nate Straz
Modified: 2010-01-12 03:40 UTC (History)
4 users (show)

Fixed In Version: RHBA-2008-0350
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 17:20:40 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch to fix the problem (847 bytes, patch)
2008-03-04 21:51 UTC, Robert Peterson
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0350 normal SHIPPED_LIVE gfs2-utils bug fix update 2008-05-20 12:44:56 UTC

Description Nate Straz 2008-03-04 13:34:36 UTC
Description of problem:

The mkfs.gfs2 man page states:

       -p LockProtoName
              LockProtoName is the name of  the   locking   protocol  to  use.
              Acceptable  locking  protocols  are lock_dlm or if you are using
              GFS2 as a local filesystem (1 node only), you  can  specify  the
              lock_nolock   protocol.    If  this  option  is  not  specified,
              lock_nolock protocol will be assumed.

But the default looks to be lock_dlm since mkfs.gfs2 complains about a bad lock
table name.

[root@marathon-01 ~]# mkfs -t gfs2 -O /dev/gfs2/gfs20
mkfs.gfs2: locktable error: missing colon in the locktable

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. mkfs -t gfs2 -O /dev/gfs2/gfs20
Actual results:
See above

Expected results:
The default should be lock_nolock as stated in the man page.

Additional info:

Comment 1 Nate Straz 2008-03-04 13:43:06 UTC
Ah, finally found bug 311591.  I knew we talked about this before.  How about
this for an idea.  If the -t option is given, default to lock_dlm.  If no -t
option, default to lock_nolock.

Either way, the man page update was missed in 311591.

Comment 2 Robert Peterson 2008-03-04 18:42:47 UTC
Adding Abhi, Steve and Dave to the cc list.

We talked about the suggestion in comment #1 about "guessing" the correct
protocol based on -t.  Personally, I liked the idea but I was overridden.
IIRC, Dave's concern was that our defaults need to be consistent.  And
since gfs2 will primarily used for clustering, the default should simply
be lock_dlm.  Therefore, I think we just need to change the man page to
reflect that.

Comment 3 Rob Kenna 2008-03-04 20:28:52 UTC
Yup, that's how the conversation went (comment #2).  We should do that for the
doc and utils

Comment 4 Robert Peterson 2008-03-04 21:51:55 UTC
Created attachment 296818 [details]
Proposed patch to fix the problem

Comment 5 Robert Peterson 2008-03-11 22:16:06 UTC
I haven't heard much feedback regarding my proposed changes, so I'm
going to assume it's alright.  There's been some more discussion lately
about whether to change the defaults again, but it's kind of late to be
making code changes.  This patch is just updates to the man page.
Requesting flags so I can fix the man page for RHEL5.2.

Comment 6 Rob Kenna 2008-03-11 22:47:15 UTC

Comment 8 Robert Peterson 2008-03-14 13:39:47 UTC
The man page change was pushed into the cluster git tree, so I'm marking
this bug modified.

Comment 11 errata-xmlrpc 2008-05-21 17:20:40 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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