From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Mon, 01 Dec 2008 15:37:03 +0000 Subject: [Cluster-devel] GFS2: Send useful information with uevent messages In-Reply-To: <20081201152531.GB24608@redhat.com> References: <1227782721.9571.134.camel@quoit> <20081201152531.GB24608@redhat.com> Message-ID: <1228145823.9571.277.camel@quoit> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, On Mon, 2008-12-01 at 09:25 -0600, David Teigland wrote: > On Thu, Nov 27, 2008 at 10:45:21AM +0000, Steven Whitehouse wrote: > > >From 04b985e291c464092516d0d1a4387b866389a85d Mon Sep 17 00:00:00 2001 > > From: Steven Whitehouse > > Date: Thu, 27 Nov 2008 09:42:51 +0000 > > Subject: [PATCH] GFS2: Send useful information with uevent messages > > > > In order to distinguish between two differing uevent messages > > and to avoid using the (racy) method of reading status from > > sysfs in future, this adds some status information to our > > uevent messages. > > > > Btw, before anybody says "sysfs isn't racy", I'm aware of that, > > but the way that GFS2 was using it (send an ambiugous uevent and > > then expect the receiver to read sysfs to find out the status > > of the reported operation) was. > > Not as long as gfs_controld tells gfs-kernel to recover journals one at a > time on a node, which is what it does to avoid this problem. > Thats true, but I think that we ought to remove that restriction. It also doesn't alter the fact that its impossible to tell the difference between the two CHANGE events except by knowing the current state of the cluster, and I don't think thats a good thing really, Steve.