From owner-freebsd-hackers Mon Feb 5 13:03:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA23486 for hackers-outgoing; Mon, 5 Feb 1996 13:03:51 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA23481 for ; Mon, 5 Feb 1996 13:03:46 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA16844; Mon, 5 Feb 1996 14:01:33 -0700 From: Terry Lambert Message-Id: <199602052101.OAA16844@phaeton.artisoft.com> Subject: Re: Solaris CacheFS for FreeBSD? To: dutchman@spase.nl (Kees Jan Koster) Date: Mon, 5 Feb 1996 14:01:32 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199602050950.KAA00543@phobos.spase.nl> from "Kees Jan Koster" at Feb 5, 96 10:50:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk > Some time ago I installed a sun workstation with a friend of mine. We > found that sun has a special filesystem called CacheFS. It can cache > remote filesystems (and CD-ROMS too, I think) on a local disk, thus > reducing network load and increasing performance. > > Is there something like it under FreeBSD? Is there a quick-'n-dirty way > to try it out and make some performance measurements? With the results > I might persuade our sysop to trash linux and use FreeBSD instead ;) This is actually a special case of a replicating FS, as opposed to a true cache. This would be relatively trivial to implement using the unionfs code as a base and working from there; many of the problems are similar in nature, and the additional piece you would need to supply is the replication from the "search second" to the "search first" FS when a "search first" fails. I would say that this would have limited utility on CDROM's, but could be very useful for local replication of NFS data on a "dataless" machine. The vnode would have to be map-directed -- that is, for a vnode that was being used as a swap store, you would have to be using the upper layer, not the lower layer vnode, if you expected the swapping to move from the remote file to the locally replicated copy. It might be more interesting to do a more comprehensive/predictive network replication for nomadic systems, since on a fast net, the benefits of replication should be marginal. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.