Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!math.fu-berlin.de!opal!gmdtub!prosun!tmh
From: tmh@prosun.first.gmd.de (Thomas Hoberg)
Newsgroups: comp.unix.sysv386
Subject: Re: DPT controller?
Keywords: DPT disk controller
Message-ID: <684@bigfoot.first.gmd.de>
Date: 23 May 91 17:07:25 GMT
References: <1991May14.235110.18644@tous.uucp> <1991May17.131717.26942@virtech.uucp> <31@metran.UUCP> <1991May22.010734.15694@nuchat.sccsi.com>
Sender: news@bigfoot.first.gmd.de
Reply-To: tmh@prosun.first.gmd.de (Thomas Hoberg)
Distribution: na
Organization: GMD-FIRST, D-1000 Berlin 10
Lines: 53

In article <1991May22.010734.15694@nuchat.sccsi.com>, steve@nuchat.sccsi.com (Steve Nuchia) writes:
|> In article <31@metran.UUCP> jay@metran.UUCP (Jay Ts) writes:
|> >I have been wondering under what conditions the DPT and other caching disk
|> >controllers are really effective enough to be worth the extra price and
|> ...
|> >cache on the controller is only about 10-15%, even if it is maxed out at
|> 
|> In an ideal world (ie, one in which you have source) you can make
|> certain trade-offs in software, where they belong, and hardware hacks
|> like caching controllers become completely irrelevant.  Without the
|> ability to make those trade-offs in software, sometimes hardware
|> is the only answer.
|> 
|> In sysV there are a number of places where synchronous writes to
|> the disk are forced.  Number one on my personal list of pet peeves
|> is unlink(2), for instance.  Using a non-write-through caching controller
|> will make rm -rf /usr/spool/news run as fast as it should instead of
|> taking about 50 ms per article.

It's about time USL implemented a NEWS file system (e.g. mount -f dispensible
/usr/news).

|> 
|> If you wanted to make the trade-off of non-synchrounous inode updates
|> for faster directory operations, and you don't have source, the only
|> way to do it is in hardware.  Depending on your jop mix it may be worth it.

Does anybody do a [E]ISA board with a battery buffered write cache?

|> -- 
|> Steve Nuchia	      South Coast Computing Services      (713) 964-2462
|> 	"Innocence is a splendid thing, only it has the misfortune
|> 	 not to keep very well and to be easily misled."
|> 	    --- Immanuel Kant,  Groundwork of the Metaphysic of Morals

Does the file system hardening (the forced synchronous writes) actually work
failsafe? I mean power can get lost at any time, even in the middle of a sector
write. A power supply can usually supply DC current for a certain period of time
after AC input is lost (right?). Does this always/usually suffice to finish the
sector write? I think the power fail line of a PC power supply triggers an NMI
on the motherboard. This should keep any further write requests from being
started, right? Basically, what I am asking: Are sector writes atomic, or have I
just been lucky? After all, if disk inode updates can be incomplete due to
partially written sectors, doesn't that invalidate file system hardening?

-- tom 
----
Thomas M. Hoberg   | UUCP: tmh@gmdtub.first.gmd.de  or  tmh%gmdtub@tub.UUCP
c/o GMD Berlin     |       ...!unido!tub!gmdtub!tmh (Europe) or
D-1000 Berlin 12   |       ...!unido!tub!tmh
Hardenbergplatz 2  |       ...!pyramid!tub!tmh (World)
Germany            | BITNET: tmh%DB0TUI6.BITNET@DB0TUI11 or
+49-30-254 99 160  |         tmh@tub.BITNET