From owner-freebsd-hackers Wed Apr 2 10:32:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA14945 for hackers-outgoing; Wed, 2 Apr 1997 10:32:55 -0800 (PST) Received: from life.eecs.umich.edu (pmchen@life.eecs.umich.edu [141.213.8.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA14938 for ; Wed, 2 Apr 1997 10:32:49 -0800 (PST) Received: (from pmchen@localhost) by life.eecs.umich.edu (8.8.5/8.8.0) id NAA07782 for freebsd-hackers@freebsd.org; Wed, 2 Apr 1997 13:31:58 -0500 (EST) Date: Wed, 2 Apr 1997 13:31:58 -0500 (EST) From: "Peter M. Chen" Message-Id: <199704021831.NAA07782@life.eecs.umich.edu> To: freebsd-hackers@freebsd.org Subject: Re: question on buffer cache and VMIO Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From terry@lambert.org Wed Apr 2 13:08:47 1997 > >All this leads to the question "How intrusive is Rio at the BIO level, >and what are the actual interface impacts that will result?". > >Effectively, those of us without battery-backed RAM, or RAM that is >somehow not persistant over a crash/boot cycle, will need to be >able to "switch Rio off", and we'll still want to get the benefit >of soft updates when we do. You're getting ahead of me--I'm still just investigating what it would take to put Rio in FreeBSD or another free Unix. Our implementation of Rio in Digital Unix caused minimal changes 1) turn off reliability-induced disk writes a) redirect bwrite calls to bdwrite b) the few places that need to write to disk (e.g. getnewbuf) call the original bwrite 2) maintain a self-contained registry of permanent data in memory. We may or may not do this in FreeBSD. 3) syncing to disk during reboot. We'd probably change this to sync during the crash in FreeBSD. 4) disable/enable write protection for the buffer cache. Our Digital Unix implementation made it really easy to turn on/off Rio while the system was running (basically via something like sysctl). Rio should have little effect on soft updates. Pete