J Chapman Flack wrote:

>>:(  = may be broken, worst thing: even a manual fsck can't repair it
>>:)  = should be ok, worst thing: some inclaimed inodes/blocks

>>             softdep, writebackcache on | no softdep, writebackcache on
>>----------------------------------------+------------------------------
>>powerfailure           :(               |           :(
>>reset                  :)               |           :(
>>kernel panic           :)               |           :(

>>The filesystem with softdep wins if writeback cache is on (wich
>>is default).

> offering the following as support:

>>See http://www.mckusick.com/softdep/ (softdep) and
>>http://sr5tech.com/write_back_cache_experiments.htm (writeback cache).

> The first I had previously read, the second I had not. The first does
> not consider writeback caching at all; strictly speaking, wherever the
> paper says a block is written to the disk, one needs to read that the
> block is placed in the drive's writeback cache.

First site, first paragraph, second sentence and second site, "The
Lesson", first sentence is what i meant.

You don't have to consider writeback cache if it is written to disk
anyways (as long as you don't loose power to the disk or your hardware is
broken this is the case). If we loose power and writeback cache is on we
have a serious problem because of reordering in the writeback cache,
softdep or not.

Maybe i have a fundamental problem to express myself in english, what i
try to say is this:

  Softdep ensures that my filesystem does not need immediate fsck (if we
  have always power).

Softdep does _not_ ensure that all my write operations are on disk, i am
aware of that.

I have to admit that i don't understand the lessons given in
/usr/share/doc/smm/03.fsck_ffs/, probably because i am just a normal user,
not a filesystem-developer.

> softdep improves performance by allowing some of those updates to be
> done *after* the initiating operation returns.  It is safer than async
> because at least it still tries to do those updates in a safe order
> (though a disk's writeback cache will reorder the writes too).

The reordering in the writeback cache is a bad thing if we loose power,
but not if we have a reset or panic. Thats why i have a ":(" at
powerfailure/softdep above.

> But compared to plain ffs without softdep and without async, softdep
> allows the disk state to lag further behind the in-kernel state of the
> filesystem.

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

> Now, if you were prepared to present experimental data somehow showing
> that softdep preserved integrity better on writeback caches in practice,
> it would be interesting to look at, and speculate why (perhaps it is
> possible that the overall reduction in traffic from softdep could have
> such a serendipitous effect - or perhaps not).  When you cited the
> 'experiments' paper I thought that's what it might be, until I looked
> and saw it did not pertain to ffs or softdep.

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

Any idea how i can simulate a kernelpanic? Would that be the same like reset?

Karsten

-- 
        Homepage, Mac68k, A/UX-Links und Shorties: www.tecneeq.de
  ()    Linux/NetBSD-Anleitungen, Forum  und Chat: www.newbie-net.de
 <\/>           GPL-guy: "Argh, they used my code! :-/"
 _/\_           BSD-guy: "Cool, they used my code! :-)"