From owner-freebsd-hackers Tue Apr 1 19:15:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA00744 for hackers-outgoing; Tue, 1 Apr 1997 19:15:56 -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 TAA00739 for ; Tue, 1 Apr 1997 19:15:53 -0800 (PST) Received: (from pmchen@localhost) by life.eecs.umich.edu (8.8.5/8.8.0) id WAA03318 for freebsd-hackers@freebsd.org; Tue, 1 Apr 1997 22:15:03 -0500 (EST) Date: Tue, 1 Apr 1997 22:15:03 -0500 (EST) From: "Peter M. Chen" Message-Id: <199704020315.WAA03318@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 Tue Apr 1 13:35:03 1997 > >This is hardware... is it going to be generally available/purchasable? The only hardware is a battery. The VM write protection is software. Those without batteries need to write to disk (or non-volatile memory); those with batteries (e.g. machine rooms, laptops) can keep data in memory if it survives crashes. >One big issue: I'm not sure how this will interact with the "soft >updates" facility described in the Ganger/Patt paper. This facility >is a planned future feature on nearly everyone's whiteboards. If you >have read the paper, I can discuss the idea of a generic implementation >that is not FS dependent (like the paper's Appendix A UFS example is) >and the ramifications that would have on FS/cache interaction. Soft updates allow you to delay metadata disk writes (just like data disk writes) without losing file system integrity. However, you will lose more metadata in a crash than before. E.g. if you mkdir then crash a few seconds later, soft updates will lose that directory (but in a way that doesn't compromise file system integrity). This is the same tradeoff that's made with data. Think of it as allowing more "data loss" without "integrity loss". Rio (my project on reliable file caches) gives you something different. It allows you to delay disk writes indefinitely, yet without losing any data in a crash. This minimizes both "data loss" and "integrity loss". Of course, Rio only works with a battery, while soft updates work without a battery. >John Dyson and David Greenman are the people to contact about documenting >this in detail. John has responded privately to me. I've been amazed at how helpful and responsive this mailing list has been to a detailed kernel hacking issue. You all deserve a raise. Pete Prof. Peter M. Chen EECS Department, 2225 EECS 1301 Beal Ave. University of Michigan Ann Arbor, MI 48109-2122 (313) 763-4472, fax: (313) 763-4617 pmchen@eecs.umich.edu http://www.eecs.umich.edu/~pmchen/