Date: Sat, 14 Sep 1996 18:35:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: proff@suburbia.net, terry@lambert.org, freebsd-hackers@freebsd.org Subject: Re: attribute/inode caching Message-ID: <199609150135.SAA00362@phaeton.artisoft.com> In-Reply-To: <199609150119.LAA30846@godzilla.zeta.org.au> from "Bruce Evans" at Sep 15, 96 11:19:02 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >POSIX mandates that the access time will be marked for update when you > >read the directory; thus it's written out, and the thrashing is expected. > > Wrong. Neither marking for update nor updating the access times requires > writing anything. In FreeBSD, writing is a side affect of thrashing the > caches and updating is often a side effect of writing. First, when the > vnode cache thrashes, the vnodes have to be updated and written to the > buffer cache. Second, when the buffer cache thrashes, the dirty buffers > containing the vnodes have to be written out. They are usually written > with delayed writes, so the writes need not more than double the overhead > for the thrashing (probably much worse in practice because of seeks). If it weren't marked, it wouldn't be written. I stand behind my statement. > >The net result of this will be that the inode data itself will not be > >cached. > > 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). Really, it wants to be device relative, not vnode relative, and yet still have the vnode mapping that makes the extra bmap per data transfer unnecessary (ie: the heart of the unification). Two lists are as easily maintained as one, IMO. 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?199609150135.SAA00362>