PATCH: Forcible delaying of UFS (soft)updates
zec at tel.fer.hr
Tue Apr 15 16:27:46 PDT 2003
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
> 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.
To achieve such a functionality, simply remove or comment out the
line in /sys/dev/ata/ata-disk.c. A cleaner method would of course be
adding another tunable knob, which would also be a trivial thing to...
> 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.
More information about the freebsd-stable