PATCH: Forcible delaying of UFS (soft)updates

[M. Warner Losh]

In message: <20030416100921.U91118 at duey.wolves.k12.mo.us>
            Chris Dillon <cdillon at wolves.k12.mo.us> writes:
: quickly.  Even with a life of two million write cycles, the
: "occasional" 30-second round of updates that happen to write the same
: bits over and over will give your flash part a life of only 1.9 years
: (2000000 writes * 30 seconds apart = 60000000 seconds to failure).
: Also, I doubt you'll actually get 2 million writes out of the average
: consumer flash part.

I've gotten 10M writes in the lab here on parts that didn't fail.
Also, that's 2M writes per cell, and the CF parts wear average.  The
reason why this happens is because there are typically more than 1
cell per part.

However, you are *MUCH* better off logging to a memory file system
with cron.  Or better yet, not running cron or not logging it at all.
We log our stuff to /var/log (and don't bother logging the cron
messages) and newsyslog to a small writable partition once a day or so
on the average.  So using this as an argument to trash fsync is not
very strong.  There are much better ways to deal with these issues for
CF systems.

You are much better off doing a read-only / with a small writable
partition for things that need to be saved (we call ours /mod).  We
have a write rate of about 10 per hours, which gives our system an
expected life in excess of 20 years.

Our company has shipped over 200 flash systems, and we've had 3
flashes fail, all due to infant mortality...

Warner