+++ This bug was initially created as a clone of Bug #479096 +++ Created an attachment (id=328343) 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. --- Additional comment from pmorgan on 2009-01-07 00:00:16 EDT --- Created an attachment (id=328344) /usr/local/bin/gfs_tune (should be /usr/bin/gfs_tune) --- Additional comment from pmorgan on 2009-01-07 00:02:04 EDT --- Created an attachment (id=328345) /etc/gfs/settune --- Additional comment from pmorgan on 2009-01-07 00:08:03 EDT --- 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. --- Additional comment from pmorgan on 2009-01-07 00:26:00 EDT --- 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. --- Additional comment from swhiteho on 2009-01-07 06:37:08 EDT --- 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.
I'll take care of this one. It's a very neat solution to have in place. Steven, please clone this bug for gfs2 and let see what needs to be changed. remount might not be an option in certain situations. Fabio
Why would remount not be an option? It works for every other fs. Also it seems much more sensible to me to have the various tweekables in fstab alongside the rest of the info about the filesystem than to create a whole new set of infrastructure for it.
yes i understand your point about fstab options. Keep in mind that in certain scenarios your filesystem might already be in use and you cannot remount. Anyway it's paranoia corner cases here I am thinking about.
Its perfectly possible to remount a filesystem thats in use though... I don't mean umount /foo; mount /foo -o someoption, I mean mount -o remount,someoption /foo So I don't think that the corner case you are referring to exists.
aaaayea... you need to prefix your words with k(ernel)remount and stuff ;) Fabio
Paul: did you test the udev.rules with any recent kernel? I am trying with a git kernel (as of yesterday) but it looks like ACTION="mount" doesn't catch anything. Not even for "well known" filesystem. udevmonitor indicates all the activity around dlm/lock_dlm and /sys/fs/gfs2. Fabio
I implemented it against the enterprise kernel in RHEL 5.1 and then cloned the bug to Fedora. I have an F10 box running 2.6.27.9-159.fc10.i686 at the moment. I'll add GFS and poke at it. Just for clarification, I assume you meant to type ACTION=="mount" (double =) and have log_priority=debug. -paul
I copied pristine your udev rule and set gfs_tune to simply echo some junk into /tmp/blabla. At the same time I was running udevmonitor --env and done the mount. /tmp/blabla was not even created. the output from udevmonitor did not show any ACTION==mount. Fabio
Just to be clear.. i couldn't test gfs1 (as it doesn't build > 2.6.27) but i used gfs2 and ext3. Poking at gfs1 code I can't see any sign of sending a mount event. Fabio
ok, i've compared rhel 5 with fedora. my scripts as provided up until now work fine under rhel5. under fedora (later kernel+tools), you're right: no mount action in udev. however, i've worked up a script to use ACTION=="add",SUBSYSTEM="gfs2" with the latest kernels. even better, i'll be able to use $name as a positional argument to gfs2_tune to apply tunables to _only_ the gfs that was just mounted. i'll clean up the scripts and post later. i want to test them a bit more before uploading to this BZ. -paul
actually, i think i'll mod the udev rules and scripts so that one set of files will support both gfs and gfs2 under both rhel5 and fedora. -paul
when you suggested ACTION==mount i was looking into all parameters passed trough that invokation to limit the gfs_tune call to that specific filesystem but you are going the exact same direction I had in mind. Fabio
Paul, is there any progress on your udev script? thanks Fabio
In upstream GFS2, gfs2_tool get/settune is deprecated (to eventually be removed) and setting parameters via the mount command will be the only option. There are currently only very few parameters for which this is not possible and all of those relate to quotas. We are working to support the generic quotactl interface to allow use of the standard quota tools and once that is complete, the way will be open to remove the gfs2_tool get/settune interface.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping