From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Teigland Date: Thu, 4 Dec 2008 15:07:55 -0600 Subject: [Cluster-devel] gfs uevent and sysfs changes In-Reply-To: <1d07ca700812041032o6f82fecew3fb93545fe64ed2d@mail.gmail.com> References: <20081201173137.GA25171@redhat.com> <1d07ca700812041032o6f82fecew3fb93545fe64ed2d@mail.gmail.com> Message-ID: <20081204210754.GA19571@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Dec 04, 2008 at 01:32:31PM -0500, david m. richter wrote: > On Mon, Dec 1, 2008 at 12:31 PM, David Teigland 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? yes > ..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. Yes, it's created in gfs_controld, and passed to mount.gfs via the hostdata string which is then passed into the kernel during mount(2). Previously, gfs-kernel (lock_dlm actually) would pass this id back up to gfs_controld within the plock op structures. This was because plock ops for all gfs fs's were funnelled to gfs_controld through a single misc device. gfs_controld would match the op to a particular fs using the id. The dlm does this now, using the lockspace id. Dave