Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!dptechno!dave
From: dave@dptechno.UUCP (Dave Lee)
Newsgroups: comp.unix.wizards
Subject: Re: Using the raw disk partition
Message-ID: <545@dptechno.UUCP>
Date: 27 Jul 90 16:23:33 GMT
References: <281@intek01.UUCP> <1990Jul26.195530.24961@cbnewsm.att.com>
Reply-To: dave@dptechno.UUCP (Dave Lee)
Distribution: usa
Organization: D.P. Technology Corp. Camarillo California
Lines: 32

In article <1990Jul26.195530.24961@cbnewsm.att.com> marz@cbnewsm.att.com (martin.zam) writes:
>I have run Oracle Databases with Raw disk for production systems on heavily
>loaded systems.  I must warn you that Raw disk uses the same Clist buffer
>pool as terminals, and therefore your system must be appropriately tuned
>to maintain data integrity.
>

Someone please tell me this isn't so !  Last I looked, Clist blocks were 64 
bytes each, with a typical small system having only ~100.  

Also the raw disk shouldn't be doing buffering at all, otherwise it wouldn't
be raw.  

>A typical symptom of exhausted Clists buffers would be losing characters
>as they are being typed in, or blocks of data missing when you cat large
>files to the terminal screen.  Now imagine that your screen is the Raw disk
>device.  You should be able to see the extent of the exposure to data
>integrity problems.

This must be be due a high interrupt overhead, loaded system, or massive
terminal activity, not the write()'s to a DISK  stealing clists.   
Very likely is that the disk has a higher interrupt priority than the
serial ports and that massive raw (ie UNbuffered) disk io causes a 
large interrupt frequency, and potentially causing missed serial io 
interrupts or data.   

How could fsck possibly work on raw devices if it was as unreliable 
as implied here.  

-- 
Dave Lee
uunet!dptechno!dave