From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Teigland Date: Fri, 5 Dec 2008 09:03:23 -0600 Subject: [Cluster-devel] gfs uevent and sysfs changes In-Reply-To: <20081205145258.GA3734@redhat.com> References: <20081201173137.GA25171@redhat.com> <1d07ca700812041032o6f82fecew3fb93545fe64ed2d@mail.gmail.com> <20081204210754.GA19571@redhat.com> <1d07ca700812041359i2fe5443by7ac229485ec36f71@mail.gmail.com> <20081204223820.GB19571@redhat.com> <1228470705.3579.12.camel@localhost.localdomain> <20081205145258.GA3734@redhat.com> Message-ID: <20081205150323.GB3734@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 Fri, Dec 05, 2008 at 08:52:58AM -0600, David Teigland wrote: > On Fri, Dec 05, 2008 at 09:51:45AM +0000, Steven Whitehouse wrote: > > In that case gfs2 should be able to generate the id itself from the > > fsname and it still doesn't need it passed in, even if it continues to > > expose the id in sysfs. > > > > Perhaps better still, it should be possible for David to generate the id > > directly if he really needs it from the fsname. > > It's not actually a crc of the fsname, but a crc of the cpg name > gfs_controld creates for the mountgroup, which is "gfs:mount:". > Also, we may at some point want to allow that generated id to be overriden > by one that's set explicitly. The fact that this id comes from gfs_controld, and becomes available only during mount, makes me think it's not well suited to be the statfs fsid. GFS should probably do it's own thing for statfs (like a hash of just the fsname) instead of depending on gfs_controld for it. With nolock the daemons won't be there, and we'd still want the same fsid to be produced.