Subject: Re: change to vfs_busy() and getnewvnode()
To: Bill Sommerfeld <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 07/07/1999 11:48:55
Dang. I sent a reply but pine core dumped. :-(
On Wed, 7 Jul 1999, Bill Sommerfeld wrote:
> Well, that still single-threads you on a per-filesystem basis; I
> think we can do better.
True. What would it take to do better?
> Also, there appears to be a bit of a mess involving aliases for device
> vnodes in getdevvp() which appears to cross filesystem boundaries.
> (I must admit I don't understand that code...)
Let me see if I can explain it a bit. checkalias (the goofy part of the
code) does two things. 1) it will generate vnode aliasings if appropriate
for the new device node, and 2) it will swap a vnode under certain special
The aliasing is so that if you do a VOP_REVOKE on a device, all of the
vnodes for that device get revoked, not just the one you found.
The swapping is to take care of a chicken & egg problem. We mount
filesystems from vnodes, but vnodes live in file systems, so where does
the vnode for the root file system come from?
What we do is create a device vnode of type VT_NON, and mount from that.
As we give it the spec_vnodeop_p op vector, all will work right & no one
will ever notice that there's no mount point for this vnode.
Then in checkalias(), whenever we find a pre existing VT_NON block device
for the vnode we were passed in, we vclean the node we found, set it's
v_op and v_tag to match the one we were passed in, and return it. The
calling code then throws away the vnode it had, and shoves its private
data into the vnode it got from checkalias().
So what happens is that we fake up a VT_NON node for the root device, and
then when we mount the root filesystem and do a name lookup on the root
device node, checkalias will get called and the vnode we're using for
root's mount point will magically be changed from a VT_NON vnode to a
vnode for the filesystem holding the device we're mounting root from.
The idea is that this lookup is finding a vnode on the root fs, so now
root is mounted from itself.
Sick things happen if you try to mount root from a device on another fs,
and then unmount that fs. I haven't tried, but I don't want to...