Date: Sat, 23 Jun 2001 13:03:37 -0400 (EDT) From: Zhihui Zhang <zzhang@cs.binghamton.edu> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Confusion with mknod() and devfs Message-ID: <Pine.SOL.4.21.0106231256390.17858-100000@opal> In-Reply-To: <3B335CE6.E7E02938@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 Jun 2001, Terry Lambert wrote:
> Zhihui Zhang wrote:
> > According to the red daemon book, alias vnodes are used to make cache
> > coherent (vp as a key). But getblk() stuff does not seem to check it.
> > This makes me feel the code is there for historical reasons.
>
> The "BSD 4.4" book was written about a system without a
> unified VM and buffer cache. The aliases it is talking
> about are the buffers hung off a file vnode and the
> buffers hung off a device vnode, from which that file
> was being read.
I think you got me wrong. I was talking about a device with
more than one names. So we can have more than one vnode for the same
device. (If there is more than one name to the same device in the same FS,
they can share the vnode, otherwise, they cannot.)
Specifically, I fail to understand why we reload the inode in
ufs_mknod():
/*
* Remove inode, then reload it through VFS_VGET so it is
* checked to see if it is an alias of an existing entry in
* the inode cache.
*/
vput(*vpp);
(*vpp)->v_type = VNON;
/* Save this before vgone() invalidates ip. */
ino = ip->i_number;
vgone(*vpp);
error = VFS_VGET(ap->a_dvp->v_mount, ino, vpp);
I wonder with the use of DEVFS, the special device aliases may no longer
exist because they are created by kernel instead of by administrators.
-Zhihui
> The reason getblk() doesn't check it is that the cache is
> maintained as coherent, so there's no need, since the
> check is intended to permit explicit coherency operations
> to take place, when necessary. There is a lot of "missing"
> code you aren't seeing that is referenced by the book.
>
> It is still possible to create aliases, but they are done
> by having multiple vm_object_t's pointing to the same data
> blocks as backing objects. This only occurs in the case
> of stacking VFS's with a non-trivial relationship (e.g.
> where the backing object contents would not be the same
> between layers). It can also occur to some small extent
> in the NFS client FS case.
>
> -- Terry
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.4.21.0106231256390.17858-100000>