Re: [Cluster-devel] GFS2: Send useful information with uevent messages
On Thu, Nov 27, 2008 at 10:45:21AM +, Steven Whitehouse wrote: From 04b985e291c464092516d0d1a4387b866389a85d Mon Sep 17 00:00:00 2001 From: Steven Whitehouse [EMAIL PROTECTED] Date: Thu, 27 Nov 2008 09:42:51 + 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.
[Cluster-devel] Re: Groupd uevent clean up
On Fri, Nov 28, 2008 at 11:07:56AM +, Steven Whitehouse wrote: LOCKTABLE=clustername:fsname LOCKPROTO=[lock_dlm|lock_nolock] to avoid all the messy parsing of the initial event string. Also I've added come further information to the two change events, so that we now have: FIRSTMOUNT=Done when the first mounter has finished and: JID=journal_id RECOVERY=[Done|Failed] when recovery has finished. Is there anything else that is useful I wonder, while I'm adding new items here? I think I've covered the important bits anyway. That's excellent, much better than the sysfs files. We'll need to keep the sysfs files around for a while, though, so we don't break the user/kernel interface. Dave
[Cluster-devel] Re: Groupd uevent clean up
Hi, On Mon, 2008-12-01 at 09:28 -0600, David Teigland wrote: On Fri, Nov 28, 2008 at 11:07:56AM +, Steven Whitehouse wrote: LOCKTABLE=clustername:fsname LOCKPROTO=[lock_dlm|lock_nolock] to avoid all the messy parsing of the initial event string. Also I've added come further information to the two change events, so that we now have: FIRSTMOUNT=Done when the first mounter has finished and: JID=journal_id RECOVERY=[Done|Failed] when recovery has finished. Is there anything else that is useful I wonder, while I'm adding new items here? I think I've covered the important bits anyway. That's excellent, much better than the sysfs files. We'll need to keep the sysfs files around for a while, though, so we don't break the user/kernel interface. Dave We also need to change groupd and the reason that I didn't resend that original patch is that with these new bits of information, it might be better to implement something a bit more generic, so that it picks up all the right bits of information. Shouldn't be too tricky to keep it backwards compatible either, Steve.
Re: [Cluster-devel] GFS2: Send useful information with uevent messages
Hi, On Mon, 2008-12-01 at 09:25 -0600, David Teigland wrote: On Thu, Nov 27, 2008 at 10:45:21AM +, Steven Whitehouse wrote: From 04b985e291c464092516d0d1a4387b866389a85d Mon Sep 17 00:00:00 2001 From: Steven Whitehouse [EMAIL PROTECTED] Date: Thu, 27 Nov 2008 09:42:51 + 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.
[Cluster-devel] gfs uevent and sysfs changes
Here are the compatibility aspects to the recent ideas about changes to the user/kernel interface between gfs (1 2) and gfs_controld. . gfs_controld can remove id from hostdata string in mount options - no compat issues AFAICT . getting rid of id sysfs file from lock_dlm - new gfs_controld old gfs-kernel old kernel provides both block and id sysfs files new daemon looks for block instead of id in sysfs - old gfs_controld new gfs-kernel old daemon looks for id sysfs file new kernel needs to provide id as well as block sysfs files Once everyone is using the new daemon, we can remove the id sysfs file from the kernel. . uevent strings to replace recover_done/recover_status sysfs files - new gfs_controld old gfs-kernel old kernel has recover sysfs files, and no new uevent strings new daemon needs to look for either sysfs files or uevent strings - old gfs_controld new gfs-kernel old daemon looks for recover sysfs files, not new uevent strings new kernel needs to provide both sysfs files and uevent strings Once everyone is using new kernel and new daemon, we can remove the recover sysfs files from kernel, and daemon can stop looking for recover sysfs files.
