[Cluster-devel] gfs uevent and sysfs changes

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

On Mon, Dec 1, 2008 at 12:31 PM, David Teigland <teigland@redhat.com> wrote:
> 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

hi david,

I know I'm a peripheral consumer of the cluster suite, but I thought
I'd chime in and say that I am currently using the "id" as passed into
the kernel in the hostdata string (I believe by mount.gfs2?) in my
pNFS work.  does the above "gfs_controld can remove id from hostdata
string" comment refer to something orthogonal, or would it affect what
gets stored in the superblock's hostdata at mount time?

..hm, sorry, I don't have the code right in front of me, but is that
"id" in the hostdata string the same thing as the mountgroup id?  if
so, then my above worry about the hostdata string is moot, because if
gfs_controld still has that info I can just make a downcall.

thanks,

  d
  .

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