[Cluster-devel] gfs uevent and sysfs changes

[David Teigland <teigland@redhat.com>]

On Thu, Dec 04, 2008 at 04:59:23PM -0500, david m. richter wrote:
> ah, so just to make sure i'm with you here: (1) gfs_controld is
> generating this "id"-which-is-the-mountgroup-id, and (2) gfs_kernel
> will no longer receive this in the hostdata string, so (3) i can just
> rip out my in-kernel hostdata-parsing gunk and instead send in the
> mountgroup id on my own (i have my own up/downcall channel)?  if i've
> got it right, then everything's a cinch and i'll shut up :)

Yep.  Generally, the best way to uniquely identify and refer to a gfs
filesystem is using the fsname string (specified during mkfs with -t and
saved in the superblock).  But, sometimes it's just a lot easier have a
numerical identifier instead.  I expect this is why you're using the id,
and it's why we were using it for communicating about plocks.

In cluster1 and cluster2 the cluster infrastructure dynamically selected a
unique id when needed, and it never worked great.  In cluster3 the id is
just a crc of the fsname string.

Now that I think about this a bit more, there may be a reason to keep the
id in the string.  There was some interest on linux-kernel about better
using the statfs fsid field, and this id is what gfs should be putting
there.

> say, one tangential question (i won't be offended if you skip it -
> heh): is there a particular reason that you folks went with the uevent
> mechanism for doing upcalls?  i'm just curious, given the
> seeming-complexity and possible overhead of using the whole layered
> netlink apparatus vs. something like Trond Myklebust's rpc_pipefs
> (don't let the "rpc" fool you; it's a barebones, dead-simple pipe).
> -- and no, i'm not selling anything :)  my boss was asking for a list
> of differences between rpc_pipefs and uevents and the best i could
> come up with is the former's bidirectional.  Trond mentioned the
> netlink overhead and i wondered if that was actually a significant
> factor or just lost in the noise in most cases.

The uevents looked pretty simple when I was initially designing how the
kernel/user interactions would work, and they fit well with sysfs files
which I was using too.  I don't think the overhead of using uevents is too
bad.  Sysfs files and uevents definately don't work great if you need any
kind of sophisticated bi-directional interface.

Dave