Date: Tue, 15 Apr 2003 16:54:51 -0500 (CDT) From: Chris Dillon <cdillon@wolves.k12.mo.us> To: Marko Zec <zec@tel.fer.hr> Cc: freebsd-stable@freebsd.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <20030415160925.U86854@duey.wolves.k12.mo.us> In-Reply-To: <3E9C5975.43755858@tel.fer.hr> References: <3E976EBD.C3E66EF8@tel.fer.hr> <20030414101935.GB18110@HAL9000.homeunix.com> <3E9C5975.43755858@tel.fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
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 only thing you would have to change for that case is make the "flush on read" optional, since the purpose would be to minimize writes, not minimize disk spin-ups which don't exist on flash parts. This would only be advantageous if delaying the writes will actually cause fewer writes to be made to the flash part than would have been made without the delay, i.e. via normal soft-updates optimizations (a file created and removed within the delay period never gets written, or delaying atime updates of oft-read files), which I'm guessing would be the case most of the time. For example, on a small flash-based firewall I currently use at home, I would use a delay time of 60 minutes or more. That would correspond to how I currently handle saving the important dynamic information kept on a memory filesystem, such as DHCP leases, which is every 60 minutes mount a small filesystem read-write on the flash part, tar up the dynamic data, and then umount the filesystem. I then have to un-tar that data onto the memory filesystem during boot. Being able to keep all of that information directly on a read-write filesystem on the flash part but delay writes for a relatively long period of time would alleviate all of that. 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. -- 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?20030415160925.U86854>