Differencies between Raw devices and File systems

[Manuel G]

Does anybody know what are the differencies between file systems and raw devices?

We know how to create file systems but we don?t know how to create raw devices.

Are raw devices better for improving disk I/O trasfer rate?

Does it help to improve busy disk time?

[Thierry Poels_1 · Accepted solution]

Hi,

years ago raw devices were a lot faster than file systems. Nowadays the difference has become much smaller. "Veritas filesystems for Oracle" (don't recall the exact name) is supposed to offer the same speed as raw devices.
Filesystems however are a lot easier to administer than raw devices and give you more freedom. Personally I was always able to avoid raw devices ;)
Have a look at Ixora's pages :
http://www.ixora.com.au/tips/creation/raw_datafiles.htm
good luck,
Thierry.

[Magdi KAMAL]

Hi Manuel,

Raw devices are character devices and file system devices are block devices.

Raw devices in conjunction with database applications in some cases are giving more performances ( because the operating system handle a minimum of specific activity on haw to deal with data to be written and read from blocks in one hand and the RDBMS take all the responsability to manage the entire space to deal with data as stream CHARACTERS) .

I would prefer to do a test in both variants to conclude on your own configuration.

For creating a character device file :

1. Change directory to your volume group which will include the raw device :
cd /dev/vg...

2. mknod NAME c major minor

NAME : the name of the raw device file ( this name must not exist before this command ).
c : Charachter file
major: 64
minor: value in hexadecimal with leading 0x ( for example : 0x00000f , the value 00000f must not exist for any other device file; you can check the existing of this value by giving the following command " ls -al ".

Magdi

[Barry O Flanagan]

Manuel,

Any i/o to raw devices wont go through the system's internal buffer cache, whereas character devices will use it. So by using the raw device name, usually something like /dev/vg00/rlvol4 or /dev/rdsk/c0t5d0, you can write direct to the disk (which probably has its own internal buffer cache anyway!).

Its faster to use raw devices - but again, it depends on your application. I believe Oracle and Informix can address raw devices. Something I've seen in relation to Informix is that sometimes the actual ownership on the raw device files have to be changed to allow Informix to write to them (not sure if thats a general thing to do though).

[Ravi_8]

Hi,

Raw devices are faster than file systems since raw devices are character devices and file systems are block devices.

[A. Clay Stephenson]

Hi Manuel,

Your question really has two parts.
The main difference between raw and block devices is buffering. In raw i/o, read/writes are done directly to the disk itself; in block i/o read/writes from a process are done to buffers in kernel memory; the kernel then at some later time does the actual i/o operation to disk. If, for example, block 321 of /dev/dsk/c0t0d0 is already in a buffer (because of an earlier operation) no disk read is necessary and the process sees the read complete much faster. When a process writes block 100 - it writes to a buffer as far as the process knows, the write is complete. The kernel (when it can steal some time) then writes block 100 to disk.

For this reason, block i/o is sometimes referred to as 'cooked' i/o. Filesystem i/o uses cooked i/o.

In the case of Oracle, in general terms the buffering is done in the SGA; if you then use
cooked i/o you double buffer the data. The real downside is that memory which could have been used as SGA buffer essentially reduntantly.

It's very easy to create raw devices, you have them already. Look under (for example) /dev/vg01. All the rlvol's are raw devices; the lvols are block devices. All you need to do is create a logical volume and not create a filesystem and you have your raw device. You can do everything with SAM.
It's actuallyu very easy to convert an oracle file to a raw file.

0) Shutdown the database
1) Create the raw logical volume (e.g) /dev/vg01/rlvol1
2) Copy the original Oracle file (e.g.) /u01/mydata.dbf to the raw device using dd. dd if=/u01/mydata.dbf of=/dev/vg01/rlvol1
3) Symbolically link the raw device to the original file.
ln -s /dev/vg01/rlvol1 /u01/mydata.dbf
4) Startup the database

You have one other way to get almost all the benefits of raw/io with the convenience of regular files. Use the OnlineJFS mount option convosync=direct,mincache=direct. This tells the filesystem to bypass the normal buffer and read/write directly to disk - just like raw i/o
and no other changes are needed. It works very well.

Now for the bad news, after seeing your other postings, it ain't gonna work. I'm going to assume that you are a wonderful DBA and a wonderful SA and you can improve things by a factor of 2 (the typical really good improvement is somewhere around 20%); you need at least a 10x improvement and the only place you casn get that is in the code.

Regards, Clay

[Manuel G]

Clay:

Give me hope please...

I don?t want to review our application at all. It works very well, the only problem is response time. I dream wiht finding a very big configuration problem causing bad performance.

What I learned last year is "if it works, don?t move it"

Thanks for your detailed explanation and thnaks all who replied.

[A. Clay Stephenson]

Hi Manuel:

I'm really not trying to depress you but just ask yourself before you change to raw i/o, resize data blocks, change buffer cache, spread i/o among more devices, etc. 'Will doubling my performance be enough?'. Realistically a 2x boost is more than you can expect; you've got to look elsewhere.

I will never forget attending a class 'Managing Oracle on HP-UX' taught jointly by HP and Oracle. One of the very first things that was said is that all this stuff you are going to learn isn't going to help more than a few percent. If the SQL is inefficient then nothing you do to the OS and Database is going to make much of a difference.

Sadly, I think that is where you are. The good news is that almost certainly, you've got only a few (hopefully one) bad joins that are killing you.

Regards, Clay

[Bill Hassell]

It's important to note that raw logical volumes are simply chunks of disk space. The use of that raw volume is defined by what you do with it. Run newfs on it and you've created a filesystem. Add the volume to swap with swapon and the logical volume is now part of swap.

However, there is no way for your application to use a raw logical volume UNLESS the application has that option (some big database vendors have this capability), and then you must backup all the data with a special utility to unload the database, then reconfigure the application to import the old database into a raw partition. If this is not possible in your application, forget about raw parititons as a solution.

Generally, bad response times are caused by applications which request massive amounts of data from one or two disks and the only fixes are:

1. Find all the files that are being heavily accessed and move them to other disk channels,

2. Change the database design to use more indexed searches rather than serial access,

3. Replace the problem disks with a high speed fibre channel and huge disk caches.

Listed in ascending order of labor and equipment costs.

Now I recognize that there are thousands of possible combinations of programs, disk channels, mountpoints, multiple CPUs, etc that enter into the equation. Like all performance issues, you have to identify which resource is limiting faster response.

Really, there are only 2: CPU and I/O. CPU means actual compute time, whether system, user or both and whether multiple CPUs can improve things. I/O is generally disk but also be LAN and things like paging(swap).
Performance tools on Unix are quite archaic and require a lot of work and understanding to interpret the results. A good book on the subject is "HP-UX Tuning and Performance: Concepts, Tools, and Methods" by Robert F. Sauers, Peter S. Weygant

There are excellent commercial tools available and you can try some of them before you buy, HP's Glance and related short-term/long-term performance products.

[Jay Newman]

Manuel,
I recently migrated a set of Sybase database servers between Unix platforms, and the issue of raw devices was actually a make-or-break for us.
With raw devices, the database was able to use asynchronous I/O, whereas the mounted file systems , or even just the block devices (/dev/vg02/lvol3 instead of /dev/vg02/rlvol3) , it was forced into synchronous I/O.
The impact ?
As soon as a large number of users hit the database, temporary locks on pages,tables, and records ground the system almost to a halt using synchronous I/O.
Using asynchronous I/O (raw devices), the database server was able to move on to another user's request while waiting for the first one to complete.
If your databases involve a large number of users hitting the database interactively, such as through a desktop application, you may see an enormous difference in performance by using raw devices.
You might want to confirm with Oracle whether they behave the same way as Sybase, i.e. able to use asynchronous I/O from raw devices.
HTH.