PATCH: Forcible delaying of UFS (soft)updates
cdillon at wolves.k12.mo.us
Wed Apr 16 09:25:05 PDT 2003
On Wed, 16 Apr 2003, Terry Lambert wrote:
> 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.
I realize they have what looks like a really big number of writes on a
human scale, but to a computer which does things methodically day in
and day out without stopping, those writes can add up relatively
quickly. Even with a life of two million write cycles, the
"occasional" 30-second round of updates that happen to write the same
bits over and over will give your flash part a life of only 1.9 years
(2000000 writes * 30 seconds apart = 60000000 seconds to failure).
Also, I doubt you'll actually get 2 million writes out of the average
consumer flash part. A little USB key drive I have here is only rated
at 1 million writes, so it would likely last less than a year under
the above conditions.
> 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.
Yeah, I already do that in the stuff I've built, I'm just saying it
would be advantageous not to have to do that in certain cases.
> > 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.
I've seen some versions of Windows do the soft-read-only thing with
FAT filesystems. I also recall surprising a FreeBSD box with a reset
button and seeing a few RW-mounted filesystems go by marked "clean"
during boot, but if we don't have soft-read-only I was probably just
imagining it, or something else was at play.
As for atimes, if you're expecting all writes to be delayed, and you
still want atimes to be updated, you'll surely take into account that
the atime updates will be delayed as well. This is all purely
optional behaviour, remember, so you should understand which bits of
your foot you're likely to shoot off when you turn it on. It's not
really foot-shooting in that case, either, as long as you're not
relying on your atimes for anything important.
> 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-).
Yes, definately. Soft-read-only combined with regular foreground
fsck's would be the way to go with the current crop of drives.
Chris Dillon - cdillon(at)wolves.k12.mo.us
FreeBSD: The fastest and most stable server OS on the planet
- Available for IA32 (Intel x86) and Alpha architectures
- IA64, PowerPC, UltraSPARC, ARM, and S/390 under development
No trees were harmed in the composition of this message, although some
electrons were mildly inconvenienced.
More information about the freebsd-fs