From owner-freebsd-chat Tue Nov 28 10:16:53 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 64EFF37B401 for ; Tue, 28 Nov 2000 10:16:50 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id LAA19205; Tue, 28 Nov 2000 11:17:19 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAABjayxL; Tue Nov 28 11:17:12 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA10149; Tue, 28 Nov 2000 11:16:31 -0700 (MST) From: Terry Lambert Message-Id: <200011281816.LAA10149@usr08.primenet.com> Subject: Re: Netbsd advances... To: blk@skynet.be (Brad Knowles) Date: Tue, 28 Nov 2000 18:16:31 +0000 (GMT) Cc: joeo@cracktown.com, chat@FreeBSD.ORG In-Reply-To: from "Brad Knowles" at Nov 28, 2000 06:31:57 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > This brings up a good question -- does FreeBSD have a unified > buffer cache? If not, is there a particular reason why? FreeBSD has a unified VM and buffer cache. I believe FreeBSD had this before a commercial UNIX did... over six years ago. But life is not all a bowl of cherries. Actually, the removal of explicit VM and buffer cache synchronization points in the FreeBSD FS implementations was arguably premature, since it makes it much harder to synchronize VM objects associated with stacked vnodes. The reason FreeBSD diked out LFS was that the LFS code was not maintained over the switch-over, and languished without a champion for long enough that the complaints about it crashing, with no patches, outweighed having it hang around in the main source tree (which is why it's in the attic). Ideally, there would be a BSD still around without a unified VM and buffer cache, and VFS code would be made portable between FreeBSD and that system, which would maintain the best of both worlds. The lack of explicit synchronization points also means it is harder to proxy operations; this means both over a network, and over the user/kernel boundary. One of the original goals of the Heidemann VFS stacking framework was to allow proxy by decriptor, so that a system which did not understand a particular VOP could still proxy it to a system which did. Another original goal was the ability to proxy over the user/kernel boundary, so that a pure VFS layer (and potentially, an impure one, which did not have the descriptor interface on both the top and the bottom) could be developed and debuged in a user space developement framework. Doing explicit coherency over a network or over a protection domain boundary requires explicit synchronization between backing objects, when those objects have different scopes (see the "nfsnode" synchronization via the pager VOPs, in the NFS code, and see some of the recent glue code that had to be added to nullfs, but still fails to completely and fully maintain object coherency in the mmap() case -- you knew msync() had to be there in user space code for a reason, right?). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message