On Fri, Jun 05, 2009 at 05:38:02PM +0100, Steven Whitehouse wrote: > > I don't know what kind of mount <dir1> <dir2> is, some form of bind mount? > > > Yes. Identical to what was being done with the gfs2meta filesystem type > previously. Its only using /mnt/gfs0 to grab an inode from which to find > out what the block device is. Doing it this way eliminates any races in > mounting the second fs root based upon the first.
Ah, I see what you're trying to do now. You're trying to mount the meta fs by mounting the normal fs with a new option. That's a relatively small special case that shouldn't be hard to deal with. It's just "delicate" :-) Reworking major designs on the scale you suggest is killing a flea with sledgehammer. Spend more time studying the details, there's sure to be a small, targeted way of handling it. > > > /sbin/mount.gfs2: bad read: Invalid argument on line 263 of file > > > /builddir/build/BUILD/cluster-2.99.12/gfs2/mount/util.c > > > > I can't find that line number in any code (version 2.99.12 appears to be > > from Oct 2008!?) But, isn't it simply complaining that you've provided > > two dirs as input args? > > > Yes, the message isn't great and we are in the process of cleaning things > like that up. It might be that it is the case, and we can simply fix that, > in which case it makes things easy. > > The question is though, if I mount the same fs multiple times, does > mount.gfs2 realise that its the same fs each time? If so, then I think we > are done in that area. Mount code (both user and kernel) obviously needs to be adapted to deal with the special meta option, the user side has never had to before (the separate gfs2meta type means it never touches the cluster infrastructure). Eliminating the mount helper and entirely reworking how mounting happens is not the way to think about this, focus on the specific problem and make minor changes to deal with it directly. The mount.gfs/gfs_controld method is pretty simple: the first time a given fs is mounted, cluster stuff happens prior to mount(2). Subsequent mounts of the same fs don't involve any cluster activity, and go right to mount(2). Per http://www.mail-archive.com/[email protected]/msg02568.html we don't do any tracking of multiple mounts of the same fs or reference counting, we leave it all to the vfs, and reverse the "cluster stuff" on the final unmount, which the vfs tells us about via uevent. Dave
