Skip site navigation (1)Skip section navigation (2)
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>