On Thu, Dec 05, 2002 at 06:25:33PM -0500, Thor Lancelot Simon wrote:
> > > Hi, a friend of mine has told me that using a drive with write caching
> > > enabled essentially negates any benefit of soft dependencies. I think I can
> > > see the logic behind that, ie if the drive reorders writes... my question
> > > is: how does one disable write cache on an ata drive? atactl does not seem
> > > to know about enabling/disabling it.
> > 
> > There's no way to do that for now. I should really add dkctl support
> > to wd.
> > 
> > However, I tried disabling write-back cache unconditinally a while ago,
> > in completely killed performances.

just to be specific, i'll post here what i told sean. having writeback cache
on allows the drive to delay and reorder writes. softdeps and journaling
fses depend on writes occurring in specific order. a drive's writeback cache
then obviously defeats the purpose of ordering those writes (which softdeps
and reiserfs, etc goto a good deal of trouble being correct).

if you want *real* protection (that is, metadata consistency) you must (on
netbsd and linux) disable write cache. using writeback cache on the drive,
you're only protected from some things (accidently hit reset, kernel panic).
you're not protected from power failure. i have a ups, but i still disable
write cache. a ups can fail, and a machine's psu can fail as well.

there was a long thread on the linux kernel list about this, a while back. i
highly recommend people read it (though, i've essentially summerized it
above).

i just got two 15k.3 18gig scsi cheetahs, and using reiserfs on linux 2.4,
write cache does speed things up, but not by much. with such low seek times,
jumping from the journal to the final destination isn't a big deal.

> What Windows does, evidently, is to disable and then re-enable write-back
> caching as barriers around performing a synchronous I/O to the drive.  This
> forces a cache flush, so you know the sync I/O went out, while letting the
> drive continue to reorder async I/O to normal files, retaining much of the
> performance benefit.  With softdep, you'd retain most of the rest -- as
> much as you could _safely_ retain, anyway.

wow. ms actually got something right. THIS is what netbsd, linux, and i bet
just about every other os lacks.

what linux and netbsd need are write barriers added to the block io layer.
midlayer drivers for ata and scsi would be responsible for enforcing them.
ata, fwih, does not have a wb command, only cache flush. so, for ata you can
use the cache flush cmd or do what thor mentions above. for scsi, i've read
you can use ordered cmd tags, so the drive will be able to reorder between
barriers, and you won't have to flush the whole write cache, like on ata.

so, until there's block layer write barriers fs code can use, you have to
disable drive write cache to truely reap the benefits of softdeps and
journals. otherwise, you may as well just mount it async.

on linux, use hdparm for ata drives and scsitools (that's what the debian
package is called) to disable it.

i only run netbsd on my indigo2, and it's drive already has it disabled and
is running softdeps. it's a 4gig 7200rpm cuda, but it's of course slow as
hell, since the indigo2 only has 5mhz 8bit scsi. i don't know what utils you
can use to toggle it on drives under netbsd.

to conclude, if you're using softdeps or have a linux box running reiserfs,
ext3, or one of the other journaling fses, you'd better disable write cache
on any mission critical machines. and i'd recommend that everyone do the
same.

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0xE6CB97DA