PATCH: Forcible delaying of UFS (soft)updates

[Terry Lambert]

Chris Dillon wrote:
> On Tue, 15 Apr 2003, Marko Zec wrote:
> > Huh... such a concept would still break fsync() semantics. Note that
> > the original patch also ensures dirty buffers get flushed if / when
> > the disk spins up, even before the delay timer gets expired.
> 
> Sorry to butt in on this thread... :-)  It just occurred to me that
> the ability to delay all writes given an arbitrary time period would
> be good for more than just laptops.  It would be great for
> non-volatile flash filesystems which have a limited write life.

The life expectancy of these devices is really, really
underestimated.  In practice, I've seen two million
write cycles from some of these in lab machines which
get rewritten pretty often.

You are actually better off with a "noatime" option, to
avoid cron beating the same set of bits once a second,
or even a read-only mount for most/all of your FS's to
avoid having to worry about writes at all.


> If the "clean" bit is set on the FS during that long delay that would
> be even slicker (does it do that already?), since if the filesystem is
> consistent thanks to softupdates it shouldn't need to be fsck'd at all
> on boot.

That's called "soft read-only".  Kirk implemented that
for the BSDI version, but not for FreeBSD or OpenBSD.  We
discussed it when he was doing the FreeBSD work on contract
for Whistle.  It's actually not that hard to do, I think,
but it's probably evil to not update access times on an FS
that's *technically* mounted read/write, if you're expecting
those semantics.

Practically, you can't really trust the BG fsck when it
comes to real disks, because you can lose whole tracks,
and if you ever do end up with an inconsistency, you are
pretty screwed if it results in a panic.  For something
that's solid state, that's less of a problem.  8-).

-- Terry