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.
Created attachment 328344 [details] /usr/local/bin/gfs_tune (should be /usr/bin/gfs_tune)
Created attachment 328345 [details] /etc/gfs/settune
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] UPDATED /usr/local/bin/gfs_tune
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 article.