From owner-freebsd-hackers Mon Nov 23 19:29:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA27030 for freebsd-hackers-outgoing; Mon, 23 Nov 1998 19:29:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA27019 for ; Mon, 23 Nov 1998 19:29:04 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id WAA26688; Mon, 23 Nov 1998 22:28:58 -0500 (EST) (envelope-from luoqi) Date: Mon, 23 Nov 1998 22:28:58 -0500 (EST) From: Luoqi Chen Message-Id: <199811240328.WAA26688@lor.watermarkgroup.com> To: cnielsen@pobox.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel threads Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 23 Nov 1998, Terry Lambert wrote: > > > it again (no, this code won't run in an unmodified FreeBSD because > > of the VFS stacking problems FreeBSD has). It starts the helper > > Is the VFS stacking problem a result of the new VM implementation? What > needs to be done to fix it? I'm curious because I was looking into writing > an encrypting VFS layer, but I decided it was biting off more than I could > chew when I discovered the VFS stacking problems. > We need a cache manager (as described in Heidemann's paper) to ensure coherence between vm objects hanging off vnodes from upper and lower layer. For a transparent layer (no data translation, such as null/union/umap), maybe we could do without the cache manager by implementing vm object sharing between upper and lower vnodes. But for a data translation layer, a cache manager is definitely required. -lq > -- > Christopher Nielsen > Scient: The eBusiness Systems Innovator > > cnielsen@scient.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message