From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Thu, 13 Aug 2009 18:14:57 +0100 Subject: [Cluster-devel] GFS2 and uevents document In-Reply-To: <20090813160202.GB8148@redhat.com> References: <1250175480.3438.4.camel@localhost.localdomain> <20090813160202.GB8148@redhat.com> Message-ID: <1250183697.3438.33.camel@localhost.localdomain> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, On Thu, 2009-08-13 at 11:02 -0500, David Teigland wrote: > On Thu, Aug 13, 2009 at 03:58:00PM +0100, Steven Whitehouse wrote: > > 2. ONLINE > > > > The ONLINE uevent is generated after a successful mount or remount. It > > has the same environment variables as the ADD uevent. The ONLINE > > uevent, along with the two environment variables for spectator and > > rdonly are a relatively recent addition (2.6.32-rc+) and will not > > be generated by older kernels. > > The standard way to know if a mount is successful is to look at the return > value from mount(2). Is a second way really needed? Will whatever userspace > code that needs the result need to wait for and collect both results? Will > both results always agree? Will the results appear in the same order? For > repeated mount/unmount of the same fs is there a way to match the ONLINE > uevent's to the specific mount call that produced it? > > Dave > To answer the questions... yes, it will be successful only if mount is successful as its done right at the end of the mount, rather than the beginning (where the ADD is sent). There is no need in general to collect both results - just filter the events that you are interested in. It is also done after all the remount argument checking has occurred, so its reporting the actual state of the filesystem as opposed to what the user might have requested. If there is an error in the remount arguments then the remount will fail and no ONLINE uevent will be sent. We could potentially change that so that it would report the status of the command and send ONLINE events even if the request is going to fail, but I'm not sure it would be useful at all. One reason for adding the ONLINE event is that we might want to add an "errors=remount-ro" option in the future, and it would be a way for gfs_controld to keep track of any resulting state change. The results will always appear in the same order with respect to each other (on the same fs) and the mount/umount commands. You can use the variables which are sent with every message (LOCKPROTO= and LOCKTABLE=) to match the ADD and the ONLINE uevents. The idea is that by adding these variables to all messages it should always be possible to match the messages belonging to a single gfs2 mount, whatever type it is. We might want to consider adding some identifier for the block device too if that proves useful. It might be possible to match the specific mount call to the uevent - I'd need to think about that and why we need to do it. At the worst we could add a new variable on ADD to print the pid or something if its required. The interface is intended to be extendible by adding new environment variables to messages as required, for example I'd like to add some additional information to the OFFLINE event at some stage so that we can detail more exactly the error which has occurred. So if we do need some way to track mount calls by adding another variable, it shouldn't be a big issue. I'm not really expecting that many userland programs will want to make use of the GFS2 uevents other than gfs_controld, but even so documenting them seems to be a good plan. I can also see possible applications of the OFFLINE uevent in triggering other events, such as notifying an administrator that something has gone wrong, for example. But thats a little way off yet I think, Steve.