Karsten Kruse wrote:
> >>See http://www.mckusick.com/softdep/ (softdep) and
> >>http://sr5tech.com/write_back_cache_experiments.htm (writeback cache).
> 
> First site, first paragraph, second sentence and second site, "The
> Lesson", first sentence is what i meant.

There's the risk in selecting sentences from a paper.  If you're going to
select from the softdep site, at least select the first two sentences, not
just the second:

  Traditionally, filesystem consistency has been maintained across system
  failures either by using synchronous writes to sequence dependent metadata
  updates or by using write-ahead logging to atomically group them. Soft
  updates, an alternative to these approaches, is an implementation mechanism
  that tracks and enforces metadata update dependencies to ensure that the
  disk image is always kept consistent.

Now you can see that softdep is one way to ensure filesystem consistency, and
that it is an alternative to the two older traditional ways, namely synchronous
writes or writeahead logging.  Ffs when you don't specify softdep uses the
first of those traditional methods, synchronous writes, to ensure consistency.
The purose of softdep's alternative is to relieve the performance hit of
doing the synchronous writes.

> I am aware that writes can be lost, but the filesystem should be fine.

Good, that's an important distinction to remember. "Filesystem fine" means
in a state with no problem fsck would detect.  Doesn't mean complete,
reasonable, or containing the information you thought was on it at the time
of the failure.

> Ok, so i have to make some tests. Here is the plan:
> 
>  - Testbox is my Workstation, x86, 700+ MB Ram, 1800mhz duron, IDE-disk
>    with 2mb cache and UDMA 5
>  - NetBSD 3_BETA
>  - one filesystem (/), writeback cache always on
>  - start a script like that:
>      #!/bin/sh
>      cp -R /usr/src ~/ &
>      sleep 30
>      echo -e "\007"
>  - if i hear the beep i interrupt
>      5 Times with powerfailure (rw,softdep),
>      5 Times with reset (rw,softdep),
>      5 Times with powerfailure (rw),
>      5 Times with reset (rw)
>  - write down what happens if i reboot

It might be better to devise a test that does a more varied mix of metadata
operations - creation, deletion, partial truncation, extension, renaming,
adding and removing links....  And the last step had better not just be
"write down what happens if I reboot" but compare the filesystem to an mtree
list or something so you don't just see "metadata looks ok" but you find out
what you did or didn't actually lose.

But something isn't really an experiment unless you've clarified going in
what hypothesis you're trying to test, and have you looked into the filesystem
details deeply enough to be able to state that clearly?  Frank Westheimer
pointed out that a few months in the laboratory can often save you a few
hours in the library.  ;)

-Chap