Bill Stouder-Studenmund <wrstuden@netbsd.org> wrote:
> Part of my interest was to see if soft updates on NetBSD got as close to 
> FSS async as it did when those papers were published, and to see how the 
> system performed across different block sizes. Especially tests that 
> generate a large amount of metadata. The perception we have is that 
> Soft Updates can trigger a flood of data when the right update is 
> triggered. The system becomes unresponsive at such a time.

Thanks for explaining this -- i'm not sure if i missed it in the earlier
part of the thread, but i was unaware that FFS soft-dep was a suspect in
the unresponsive-systems-during-heavy-io problems.  I can see how that
might be the culprit.  When i encountered that in NetBSD 2.x, the first
thing that it reminded me of was similar symptoms under Solaris 2.5.1
after Sun made the Solaris' buffer cache much more aggressive.

 If i can scrounge up some free time, i will try some comparisons between
FFS-async and FFS-soft-updates.

> 2) the perception that running with soft updates is too similar to using
> ffs in asynchronous mode. Yes, it's fast. However when something goes
> wrong, you're left with a spectacular mess.

 Yep.  I thought that one of the benefits of soft updates' ordered writes
is that in the worst case system crash scenario, the most one would loose
would be 20 seconds of metadata.  However, if when you say "something goes
wrong," you are referring to a bug in the soft updates code that does
something not in the design, then the consequences could be quite
gruesome, as with any bug of that type in any sort of file system code.

> We know we need to work with ext3fs,

 That would be good.  I dislike Linux, but it's a reality, and being able
to mount its file systems can be useful.

 Thank you for explaining.


 -johan