Date: Mon, 16 Sep 1996 11:05:55 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dg@root.com Cc: terry@lambert.org, bde@zeta.org.au, proff@suburbia.net, freebsd-hackers@FreeBSD.org Subject: Re: attribute/inode caching Message-ID: <199609161805.LAA02580@phaeton.artisoft.com> In-Reply-To: <199609150333.UAA05077@root.com> from "David Greenman" at Sep 14, 96 08:33:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> It could be hung off the vnode for the mounted device. I'm not sure if > >> it isn't already. This problem is secondary. Repeated tree traversals > >> aren't all that common, and you don't really want them to eat the buffer > >> cache (you probably want to buffer precisely the inodes and directories > >> that will be hit again a long time later in the same search, e.g., > >> intermediate directories for a depth-first seach). > > > >It is not hung off the vnode for the device. It probably should not be, > >in any case (there is no "device" for NFS, for instance). > > Inode blocks are hung off the device vnode. I find this hard to believe. This would imply a limitation of the device size of the file size, since the adressable extent for a vnode is smaller than the addressable extent for a device. Which value are you caliming is in error? It seems to me that if inode blocks are hung of the device vnode (so why have the ihash?!?), then it is an error to not limit the device size to the max file size. The fact that the device size was allowed to be larger than the max file size was one of the justifications John Dyson gave for not using caching based on device/extent instead of (in addition to) vnode/extent in order to keep the buffer cache unification of the vnode/extent mapping, but resolve a lot of other issues. For instance, if the device vnode is in fact a device/extent cache, then there is no need for the ihash, since the inodes are determiistically layed out and thus indexable by fault. In addition, the abilit to address device blocks by fault on the device vnode means that vclean is totally unnecessary. I think you might be confusing what I have been arguing for for over a year (a device/extent-based block cache) with reality? > Indirect blocks are hung off the file vnode (using negative block numbers). I knew this already; indirect blocks aren't the issue, since they are per vnode objects in any case (though there are a number of sign extension issues that should be addressed for the 32/64 bit problem). If we had a full 64 bit space, we could use page anonymity protection instead of relying on much-more-costly premapping. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609161805.LAA02580>