Red Hat Bugzilla – Bug 479096
suggest ENHANCEMENT for gfs_tool settune
Last modified: 2010-08-02 09:49:43 EDT
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.
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.
Add the attached files to gfs_utils RPM:
/usr/local/bin/gfs_tune (recommend /usr/bin/gfs_tune)
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
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.
Created attachment 328344 [details]
/usr/local/bin/gfs_tune (should be /usr/bin/gfs_tune)
Created attachment 328345 [details]
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.
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.
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.
Created attachment 328498 [details]
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.
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