PATCH: Forcible delaying of UFS (soft)updates

[Marko Zec]

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
stratcalls++
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...
Cheers,

Marko

> 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.