Re: The old raw devices chestnut.

"Jim Smith" <jim_at_jimsmith.demon.co.uk> wrote in message news:dS4PuczgskeAFwJq_at_jimsmith.demon.co.uk...
> This question was prompted by a thread on the a postgres mailing list
> during which someone (Gregory Williamson) claimed
>
> <quote>
> raw devices, at least on Solaris, are about 10 times as fast as cooked
> file systems for Informix.
> <quote>
>

Let's see first if we can all understand what the heck is meant by "faster"?

Is it faster I/O requests?
Or faster I/O overall?
Or less CPU used?

Here is IME:

1- Raw does not make for "faster" I/O. I/O speed is defined by your hardware (disk + controller) and raw or cooked means nothing in that context.

2- Raw produces overall faster I/O response, all else being equal.

3- However, this can be MUCH faster, or slightly faster.

Explain:

If db is reading off the file system buffer cache, then it is eminently STUPID to claim "file system I/O" is faster: there is no I/O in that case, just in-memory access!

If db is reading from disk to fs cache and then copying from there to db cache then raw will be faster: it doesn't need to copy into the fs cache, I/O goes directly to the db cache. In such cases one notices a marked drop in CPU use(!) rather than I/O use by switching to raw: the block/page copy doesn't come cheap or free.

If the fs cache allows for referencing via pointers from the db processes, then the fs I/O will be almost same speed as raw but CPU use will be a little higher: use of indirect addressing (via pointers) is slightly heavier on resources than direct addressing (via segment addressing).

However a fs cache will be servicing requests from the ENTIRE system, not just the database hardware. So the potential for heavy interference with the db I/O activity is there. As such if the system is not a dedicated db server, one can see some wild variations in I/O response times with varying system loads.

It all depends on what is being measured, and when and how.

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam