The old raw devices chestnut.

Note the cross-posting - but no flame wars please. 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> This made me think about the old arguments, and I wondered about the current state of thinking. Some of my knowledge will be a bit out of date. Oracle: (my main experience) At various times Oracle have claimed (talking to consultants, not marketers) that raw devices are 5-20% faster than filesystems. This may vary on the current state of the oracle code and/or the filesystem being compared against. Veritas seem to agree by producing QuickIO for Oracle, claiming "performance of raw with the management of filesystem". I have never been sufficiently convinced to implement a major system with raw. Sybase: (some experience) Sybase claim filesystems are faster, because of OS buffering, but unsafe for the same reason. They only ever suggest filesystem for tempdb. They don't seem to have heard of fsync()[1] DB2: No idea Informix: No idea beyond the claim which started this off. What is the latest thinking, both in terms of vendor claims and practical experience? [1] or whatever system call forces write-through caching -- Jim Smith Because of their persistent net abuse, I ignore mail from these domains (among others) .yahoo.com .hotmail.com .kr .cn .tw For an explanation see <http://www.jimsmith.demon.co.uk/spam>;

"Jim Smith" <jim@jimsmith.demon.co.uk> wrote in message news:dS4PuczgskeAFwJq@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@yahoo.com.au.nospam