RAW devices

In computing, specifically Unix-like operating systems, a raw device is a special kind of block device file that allows accessing a storage device such as a hard drive directly, bypassing the operating system's caches and buffers (although the hardware caches might still be used). Applications like a Database management system can use raw devices directly, enabling them to manage how data is cached, rather than deferring this task to the operating system.

On FreeBSD, all block devices are in fact raw devices. Support for non-raw devices was removed in FreeBSD 4.0 in order to simplify buffer management and increase scalability and performance.

On Linux raw devices are deprecated and scheduled for removal, because the O_DIRECT flag can be used instead.Instead of accessing a special raw device file, the application simply can (and should!) access a file with the O_DIRECT flag enabled, and caching will be disabled. Since there is still a userbase for raw devices and applications without support for O_DIRECT still exist, it has been a controversial subject on the Linux kernel mailing list.Raw devices are character devices (major number 162). The first minor number (i.e. 0) is reserved as a control interface and is usually found at /dev/rawctl. A utility called raw (see man raw) can be used to bind a raw device to an existing block device. These "existing block devices" may be disks or CDROMs/DVDs whose underlying interface can be anything supported by Linux (e.g. IDE/ATA or SCSI).

Lets say you are using a unix buffered file system. Your system does more physical IO then it should due to poorly tuned applications. You want to make things go faster. You've heard that "raw is faster" so you move your files to raw. The next day it is REALLY REALLY slow. What happened? Well, your system was double buffered. There was the Oracle cache, and the OS file system cache. maybe 90% of your "physical io" when using the cooked (non-raw) file system was satisfied via the unix buffer cache. So, only 10% of your physical IO really went to physical disk. When you moved it to raw -- you took that cache away -- now 100% of your physical IO is TRUE physical IO, really goes to disk. You just killed performance (because you tried a quick fix to fix your problem instead of fixing the problem -- the way to fix IO related issues is generally to DECREASE your IO ;) Conversely, you are using a unix buffered file system. Your system does more physical IO then it should due to poorly tuned applications. You want to make things go faster. You've heard that "raw is faster" so you move your files to raw. The next day it is marginally *faster*. What happened? Well, you apparently didn't make much use of the unix buffer cache, perhaps your SGA was so large and the PGA's just crowded the unix buffer cache out so 90% of your physical IO was true physical IO. You are seeing the nominal increase in performance of RAW disk IO over cooked. Conversely, you are using a unix buffered file system. Your system does more physical IO then it should due to poorly tuned applications. You want to make things go faster. You've heard that "raw is faster" so you move your files to raw. The next day it is really really fast. What happened? Perhaps you removed an IO bottleneck. In short -- what you need to do is o determine cause of poor performance o develop a custom plan to remove that cause Just moving files -- well, maybe you get lucky once out of one hundred times but more typically it makes it worse, makes is marginally better or does nothing whatsoever.