Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Apr 1997 22:15:03 -0500 (EST)
From:      "Peter M. Chen" <pmchen@eecs.umich.edu>
To:        freebsd-hackers@freebsd.org
Subject:   Re: question on buffer cache and VMIO
Message-ID:  <199704020315.WAA03318@life.eecs.umich.edu>

next in thread | raw e-mail | index | archive | help
>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/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704020315.WAA03318>