Date: Wed, 16 Apr 2003 11:25:02 -0500 (CDT) From: Chris Dillon <cdillon@wolves.k12.mo.us> To: Terry Lambert <tlambert2@mindspring.com> Cc: David Schultz <das@freebsd.org> Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <20030416100921.U91118@duey.wolves.k12.mo.us> In-Reply-To: <3E9D157E.96FD09AE@mindspring.com> References: <3E976EBD.C3E66EF8@tel.fer.hr> <20030414101935.GB18110@HAL9000.homeunix.com> <20030415160925.U86854@duey.wolves.k12.mo.us> <3E9D157E.96FD09AE@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030416100921.U91118>