Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!nisca.ircc.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!virtech!cpcahil
From: cpcahil@virtech.UUCP (Conor P. Cahill)
Newsgroups: comp.unix.i386
Subject: Re: ESDI controller recommendations
Message-ID: <1127@virtech.UUCP>
Date: 5 Sep 89 01:07:05 GMT
References: <121@mdi386.UUCP> <1474@wb3ffv.ampr.org> <4843@looking.on.ca> <72@calcite.UUCP>
Organization: Virtual Technologies Inc
Lines: 40

In article <72@calcite.UUCP>, vjs@calcite.UUCP (Vernon Schryver) writes:
> 
> Running fsck thru the buffer cache helps.  You don't suffer some of the
> inconsistencies that otherwise occur.  Most of the need for the "reboot-no
> sync" message goes away.  (BTW, in SVR3 for separate reasons, fsck does not
> say that; it automatically re-mounts root.)  As long as the character
> device reads & writes the correct bytes quickly, what does it matter to a
> user process such as fsck how the driver (which many consider part of the
> SVR3 kernel, even if it need not be in MACH) does its thing?

There is a big difference for programs that wich to read lots of data
from a disk partition.  I have used database software that allows a user
to specify raw volumes for portions of the database.  The database used
the raw partitions for backups/restores and sequential access.  Using
the raw interface with a 200K blocking factor allowed the data to 
be processed about an order of magnitude faster than using the blocked
interface.   I think the user would notice this (in fact he did, when
I wrote a replacement program for the restore program and forgot
to use the raw device, it took over 3 hours to do what normally would
be a 20-30 minute operation AND the entire system was at a standstill).

In another response you made references to the bad coding in the 
System V OSs available for the i386 and said the solution could be
solved by fixing the OS.  I don't have the money to buy a source 
liscence ?sp?, nor the time to spend making a fix to gain some
additional performance when I can buy a hardware solution for a lot 
less.  Besides as I said before, most larger systems do not 
have all the i/o brains in the OS, they use dedicated I/O subsystems
to do all that work.

As a side note, I do not have anything to do with DPT, I am just an 
end user who is very satisfied with the performance of my system using
the DPT board.


-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+