Date: 21 Apr 1999 11:32:19 +0300 From: Ville-Pertti Keinonen <will@iki.fi> To: dg@root.com Cc: hackers@freebsd.org Subject: Re: Directories not VMIO cached at all! Message-ID: <86r9pejrvw.fsf@not.demophon.com> In-Reply-To: dg@root.com's message of "21 Apr 1999 00:00:13 %2B0300" References: <199904201928.MAA99383@apollo.backplane.com> <199904202056.NAA11478@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
dg@root.com (David Greenman) writes: > I prefer the current architecture, actually. Several problems come to > mind with your proposed scheme: On for example is problems with handling > filesystems with block sizes less than a page. I think there are a lot of Perhaps the "page-block-sizes" should only be sub-pages if there is only a sub-page's worth of data left in the object (sort of like ffs end fragments). This would mean that the valid/dirty masks wouldn't be discarded. And you certainly don't need a short for size, two bits are enough if you stick to powers of two. The size of struct vm_page wouldn't need to change, nor would the ability to track finer-granularity validity and dirtyness for pages without having multiple headers. Then there's the case of mmapping the last (possibly sub-page) block, which would require extending it to a full page, breaking the size "rule"...more special cases - not good. But one can also argue that the complexity in ffs for dealing with end fragments isn't good, either, but for a block-based filesystem, it is quite beneficial. If I had any influence over the matter, I wouldn't make any quick judgements as to whether Matt's suggestion is useful or not. I've seen the idea of getting rid of the separate buffer cache altogether mentioned a few times - if this is something that FreeBSD intends to do, then memory is either going to be wasted by fragmentation or sub-page vm_page allocations eventually need to be supported. Not necessarily using the first scheme presented, of course. If the buffer cache is here to stay...isn't it philosophically wrong to use vm_pages for general-purpose caching when there are bufs that exist for this purpose (even if the storage is actually shared)? Maybe not if the purpose of bufs is redefined, but redefining their purpose could make replacing their current use with a kind of "block I/O request" with a much shorter lifetime more appropriate. And this would effectively get rid of the buffer cache. > other problems, too, but I'm too busy to go looking for them. I don't > really see how it fixes anything, either - the wastage for directory blocks > will still be there unless you create fictitious pages and/or support offsets I always thought that the use of the term fictitious referred to the fact that the placeholders don't have associated memory, rather than the fact that they aren't statically allocated per-page. 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?86r9pejrvw.fsf>