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
