Date: Tue, 21 May 2002 15:57:14 -0700 From: Maxime Henrion <mux@freebsd.org> To: arch@FreeBSD.org Cc: Terry Lambert <tlambert2@mindspring.com> Subject: Re: a virtual fs to allow root mounting of any fs without special code Message-ID: <20020521225713.GJ496@elvis.mu.org> In-Reply-To: <3CEABFCF.35B80817@mindspring.com> References: <Pine.NEB.3.96L.1020521172613.79313X-100000@fledge.watson.org> <3CEABFCF.35B80817@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > Robert Watson wrote: > > > You need to do exactly what you said you don't want people doing, in > > > order to achieve proper jails that are indistinguishable by way of the > > > root mounts. > > > > What I'm saying is that if it's a limited-purpose file system that doesn't > > follow the normal conventions for vnodes and their relationship to a > > struct mount, we need to prevent people from mis-using the file system, as > > it will violate existing code assumptions about the presence of a struct > > mount under certain circumstances. If we would like people to be able to > > mount it just about anywhere following boot (as with any other synthetic > > file system), we'll need a heavy-weight struct mount, which rootfs > > currently doesn't have. > > I think if it's integrated, it needs a "struct mount". Why ? I used to have a "struct mount" in my code. It's just not needed, and makes the code bigger. I've monitored all VOP calls during the root mounting sequence. rootfs never gets called from anything else but the code I added in vfs_conf.c and by the VFS_MOUNT functions of the root filesystem (which is the purpose of it). All 3 vnodes get recycled after the root mounting (VOP_RECLAIM + VOP_INACTIVE). > Personally, I'd like to see the "real" root union mounted over it. I've already tried this. There are exactly 3 hooks for MNT_UNION in the code, one in lookup(), one in getdirentries(), and one in getdirentries(). If you look at the code, you will see that these hooks only occur when looking for a file while at the VROOT vnode. So when I have devfs in /dev (as I need it to be for the filesystem to mount) and when I mount the real fs on top of it on /, the mount union is actually between the real fs and rootfs, which in my tests was getting lookup for /.profile (as I don't have it on my real fs). To have MNT_UNION working you would need to ensure that the real fs has no /dev directory (an empty /dev is not enough), so that the lookup for "/dev" fails and that you are able to give the devfs /dev for hte rest of the lookup to work. It also has the disadvantage of leaving rootfs active in the kernel during its whole lifetime whereas in my code it gets only used at root mounting. There is however one thing I could do to simplify rootfs even more, which is before mounting the real fs on /, do a lookup for /dev, retain the vnode, then mount the real fs normally on /, and call dounmount() to unmount the devfs under it after this. This could reduce rootfs to a 2-vnodes filesystem but I didn't test it yet. > > That said, I'm not sure what you're saying applies. There's nothing > > special about "rootfs" itself, it's pretty minimalist, what's special > > about it is that it gives you a place to stick devfs during the bootstrap > > (etc) so that you can get rid of special mountroot mounting procedures for > > other file systems. I.e., the magic in Maxime's patch is in the > > general-purpose root mounting case in the boot code, not in rootfs itself. > > I was really torn on this patch, so I didn't say anything > previously: it implements part of one of my suggestions, but > it tends to encourage people to not implement the correct > solution to root vs. non-root mounting, since it offers a > workable workaround to doing the right thing (seperating the > mount-into-mountlist from the mount-into-fs-hierarchy is the > cannonically correct approach). > > Now that you've implied the very thing I feared, I guess I > need to say something. > > I would be really unhappy if the mount during boot ended up > being significantly different than the mounting after boot. > 8-(. Fine, my patch precisely intends to make them the same, since with it we are now able to mount the root filesystem the very same way we mount other filesystems, that is, via their VFS_MOUNT function without any special code. BTW, if you use MNT_UNION, you are the one making things more different. > There really needs to be a new VFSOP "MOUNTEDON", used to set > the "last mounted on" information, which is the main difference > (from an FS perspective) between root and non-root mounts. The > vnode overlay is also a difference, but it's really obvious how > this could be handed in an FS independent manner in higher level > FS independent code (this is where the mount-into-fs-hierarchy > should be done). I don't think I understand what you're saying. Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020521225713.GJ496>