Bug 479096

Summary: suggest ENHANCEMENT for gfs_tool settune
Product: Red Hat Enterprise Linux 5 Reporter: Paul Morgan <pmorgan>
Component: gfs-kmodAssignee: Robert Peterson <rpeterso>
Status: CLOSED WONTFIX QA Contact: Cluster QE <mspqa-list>
Severity: medium Docs Contact:
Priority: low    
Version: 5.4CC: iannis, rwheeler, sghosh, swhiteho
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-02 13:49:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 479138    
Attachments:
Description Flags
udev rules file
none
/usr/local/bin/gfs_tune (should be /usr/bin/gfs_tune)
none
/etc/gfs/settune
none
UPDATED /usr/local/bin/gfs_tune none

Description Paul Morgan 2009-01-07 04:58:34 UTC
Created attachment 328343 [details]
udev rules file

Description of problem:
gfs_tool settune must be run after mount on every node that mounts a gfs.

Currently there is no clean way to do this.
  /etc/rc.local? yuck
  wrapper around mount command? yuck

Red Hat customers face this every day.
Students in the RH436 (Storage and Clustering) are presented with
no clean solution from Red Hat.Attached files allow udev to detect when a gfs is mounted, then
runs gfs_tune script, which sources
/etc/gfs/settune and applies tunables to gfs filesystems.


Suggested enhancement:

Add the attached files to gfs_utils RPM:
  /etc/udev/rules.d/75-gfs.rules
  /usr/local/bin/gfs_tune (recommend /usr/bin/gfs_tune)
  /etc/gfs/settune

When implemented, the attached files enable:
1. udev detects when a gfs is mounted
2. runs gfs_tune, which 
3. sources /etc/gfs/settune to
4. apply tunables to mounted gfs filesystems

If these file are added to gfs_utils, then Red Hat can provide
an out-of-box solution for persistent tunables on gfs that apply across
all nodes. 

The style of the config is modeled after the traditional route-eth?,
such that a simple config consists of the tunables applied to each
gfs mountpoint. The script is human-readable and commented,
including commented examples.

Comment 1 Paul Morgan 2009-01-07 05:00:16 UTC
Created attachment 328344 [details]
/usr/local/bin/gfs_tune (should be /usr/bin/gfs_tune)

Comment 2 Paul Morgan 2009-01-07 05:02:04 UTC
Created attachment 328345 [details]
/etc/gfs/settune

Comment 3 Paul Morgan 2009-01-07 05:08:03 UTC
attached file gfs_tune probably needs to be modified to distinguish between gfs and gfs2 filesystems. It works for me on gfs, not tested against gfs2.

Comment 4 Paul Morgan 2009-01-07 05:26:00 UTC
i suspect the compromise on performance of re-establishing tunables
on an all already-mounted gfs filesystems is better than the work-arounds 
(incl. semaphors) of detecting which single gfs was most-recently mounted.
iow, i suspect that it would be more expensive to detect which
gfs we just mounted than it is to simply apply the tunables.

Comment 5 Steve Whitehouse 2009-01-07 11:37:08 UTC
This looks ok for gfs, I think. For gfs2 I think we'll want a different method. Firstly a lot of the tunables have gone in gfs2, secondly we need gfs2_tool rather than gfs_tool, and thirdly, if such a tunable is really needed I'd prefer to make it a mount option and change it with remount as required. Once the new remount parsing patch (which we might want to back port to gfs1) has gone in, that will be easy to do.

Comment 6 Paul Morgan 2009-01-08 22:15:39 UTC
Created attachment 328498 [details]
UPDATED /usr/local/bin/gfs_tune

Comment 8 Steve Whitehouse 2010-01-26 20:10:58 UTC
We can now do pretty much everything with mount options in GFS2. If we do anything for GFS then I think we'll back port the mount options rather than make this a special case.

Comment 11 Robert Peterson 2010-08-02 13:49:43 UTC
Closing this as WONTFIX as previously discussed.  While this may
be a good idea, I'd rather keep this as something that users can
do to enhance their GFS rather than built into it.  Perhaps
someone can follow Steve's advice and make this into a kbase
article.