Using the raw disk partition

[Jim Hutchison]

In <1990Jul26.195530.24961 at cbnewsm.att.com> marz at cbnewsm.att.com (martin.zam):
>In article <281 at intek01.UUCP> uunet!intek01!mark (Mark McWiggins) writes:
>: I've read of databases that let you use the raw disk partition instead
>: of ordinary files.  We do real-time factory automation work, and it
>: occurs to me that, if this is a significant speed win, this might be
>: worth looking into for some of our own applications [...]

Raw disk allows you to get the data straight from the disk into your programs
buffer.  You end up getting "stuck" doing I/O in multiples of your disk's
sector size (probably 512 bytes), since most disk drivers will not give
fractions of a sector.  (Aside: this is theoretically possible with SCSI)

You avoid the copy, and you loose any benefits the Unix buffer cache may have
given you.  The buffer cache loss is more of a hit when you write to the raw
device, because you loose Unix's delayed write feature.  If you aren't writing
and your data accesses are such that they would never get a buffer cache hit,
you don't loose anything on that score.  Note that the kernel still makes
sure that you can't use the device to write on other people when it does the
lock-in-physical-memory to make your buffer an I/O target/source.

Your mileage may vary, this is from an FPS 500 which is a derivative of
BSD 4.2/3 with system V extensions.  The same is said to be true on our
future machines, and reads-as-true in the Tahoe source I have.  System VrX
may do something else.

--
-
Jim Hutchison   	{dcdwest,ucbvax}!ucsd!fps!hutch
Disclaimer:  I am not an official spokesman for FPS computing