Date: Wed, 16 Apr 2003 01:34:06 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Chris Dillon <cdillon@wolves.k12.mo.us> Cc: David Schultz <das@freebsd.org> Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <3E9D157E.96FD09AE@mindspring.com> References: <3E976EBD.C3E66EF8@tel.fer.hr> <20030414101935.GB18110@HAL9000.homeunix.com> <20030415160925.U86854@duey.wolves.k12.mo.us>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E9D157E.96FD09AE>