[Cluster-devel] gfs uevent and sysfs changes

[david m. richter <richterd@gmail.com>]

On Thu, Dec 4, 2008 at 5:38 PM, David Teigland <teigland@redhat.com> wrote:
> 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.

yes, the numerical id gets used a lot in my pNFS stuff, where the
kernel needs to make upcalls, of which some then get relayed over
multicast -- so, I've just been stashing that in the superblock.
thanks for clearing up my questions.


> 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.

interesting; that'd be cool.  i've been meaning to look at statfs more
often in my stuff anyway.


>> 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.

great, thanks -- always good to get folks' anecdotal advice and keep
it in my toolbag for later.

cheers,

  d
  .

>
> Dave
>
>