Date: Wed, 16 Apr 2003 23:10:06 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Marko Zec <zec@tel.fer.hr> Cc: Kirk McKusick <mckusick@beastie.mckusick.com> Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <200304162310.aa96829@salmon.maths.tcd.ie> In-Reply-To: Your message of "Tue, 15 Apr 2003 20:37:47 %2B0200." <3E9C517B.6039679A@tel.fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3E9C517B.6039679A@tel.fer.hr>, Marko Zec writes: >Tempted by a lot of opposition to the concept of (optionally) ignoring >fsync() calls when running on battery power, I wonder what effect the >concept of unconditional delaying of _all_ disk updates by ATA-disk >firmware will make on FS consistency in case of system crash or power >failure? I do not want to imply such a concept is a priori bad, however >I fail to realize its advantages over OS-controlled delaying of disk >synching. Note that the ATA "delayed write" mechanism only delays writes while the disk is spun down; at other times there is no change in behaviour. Since the disk only spins down after it has been idle for a time, it is very unlikely that the disk is left in an inconsistent state while it is stopped. Just after the disk spins up there is a small window where the cached writes get written out in a burst. Due to the amount of cached data and the probable re-ordering of writes, the disk is quite likely to be in an inconsistent state during this flurry of writes, but the window is short so it is probably not a big issue in practice. The main advantage of using the ATA delayed write mechanism is that the disk itself can take advantage of knowing whether or not it is spinning, whereas the OS does not have that information. The downside is that it is not guaranteed that fsync'd data gets written to disk immediately, though in practice the disk tends to be spinning when the fsync is performed due to the previous accesses. I've been using ATA delayed writes on a few laptops for over a year and it has never caused me any problems - it generally works just right in the sense that the disk remains spun down when the machine is mostly idle, and spins up when you save files from an editor etc. Doing the write delaying in the OS is always going to be a tradeoff between excessively delaying writes when the machine is busy and maximising the time between spin-ups when idle, though obviously there is more control possible over which writes get delayed and which don't. Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304162310.aa96829>