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:<fsname>". > 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.
