[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] GFS2 and uevents document



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]