Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!diku!dkuug!dde!be
From: be@dde.uucp (Bjorn Engsig)
Newsgroups: comp.databases
Subject: Raw partitions (was: Re: Unix machines for large databases)
Summary: Raw partitions vs. files
Message-ID: <439@Aragorn.dde.uucp>
Date: 24 May 88 07:30:58 GMT
References: <564@hscfvax.harvard.edu> <3102@edm.UUCP> <2728@geac.UUCP>
Organization: Dansk Data Elektronik A/S, Herlev, Denmark
Lines: 33

In article <2728@geac.UUCP>, john@geac.UUCP (John Henshaw) writes:
> In article <3102@edm.UUCP> news@edm.UUCP (news software) writes:
> >From article <564@hscfvax.harvard.edu>, pavlov@hscfvax.harvard.edu (G.Pavlov):
> >#   But using raw disk i/o per se doesn't guarantee anything, does it ?
> >
 [ ]
> In the case of UNIX, this is rather important. The UNIX kernel buffers
> reads/writes from/to disk. This has the effect of not being able to offer
> "guarenteed delivery" of buffers to disk.
 [ ]
> UNIX does offer "raw data partitions" in which the program has control over
> the disk space. However, all I/O to this area is "blocked I/O",
 [ ]
> Raw disk I/O guarentees forced writes at the expense of throughput.
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is not always the case.  On our multi CPU Unix system, we run
ORACLE, and it is always run on raw partitions for several reasons:

1) The guaranteed delivery is important for safety, and ORACLE offers
   it's own buffering mechanism which ensures the efficiency.

2) The throughput is *improved*, since all file system handling is
   bypassed.  ORACLE is typically running on very few and very large
   files, say two files of ten to several hundred megabytes, and
   several levels of index blocks would be needed in the Unix file
   system.

-- 
Bjorn Engsig @ Dansk Data Elektronik A/S, Herlev, Denmark

Email: be@dde.dk			Phone:	+ 45 2 84 50 11
Email: ..!uunet!mcvax!dkuug!dde!be	Fax:	+ 45 2 84 52 20