By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,017 Members | 979 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,017 IT Pros & Developers. It's quick & easy.

Raw I/O on Linux

P: n/a
I have read that raw i/o on Linux has been depricated and support for
it might be removed from future kernal releases. I am trying to assess
what impact this has.

My current db was built on kernal 2.4 and later upgraded to 2.6. The
tablespaces were built using the raw device name as in :

create tablespace dms1 managed by database using (device
'/dev/raw/raw1' 1234)

I assume that someone issued the proper 'raw' command to bind/map
/dev/raw/raw1.

Now that I we have upgraded to 2.6 kernal, A list tablespaces still
reveals the containers are still referencing /dev/raw/raw1.

My questions are as follows -

1. Does creating a new dms tablespace using the Direct IO (using device
'/dev/sda') method do anything for me besides omit a layer of mapping
? Performance gains ? Other ? It looks looks only a mapping to me.

2. "Should I" & "Can I" change the db containers that the current
tablespace references from /dev/raw to /dev/sda.

3. If I leave my tablespace containers referencing /dev/raw/raw, then
how do they map to /dev/sda ? I assume that I still require the
issuance of the 'raw' command unless I create a new tablespace.

May 3 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a


mike_dba wrote:
I have read that raw i/o on Linux has been depricated and support for
it might be removed from future kernal releases. I am trying to assess
what impact this has.

My current db was built on kernal 2.4 and later upgraded to 2.6. The
tablespaces were built using the raw device name as in :

create tablespace dms1 managed by database using (device
'/dev/raw/raw1' 1234)

I assume that someone issued the proper 'raw' command to bind/map
/dev/raw/raw1.

Now that I we have upgraded to 2.6 kernal, A list tablespaces still
reveals the containers are still referencing /dev/raw/raw1.

My questions are as follows -

1. Does creating a new dms tablespace using the Direct IO (using device
'/dev/sda') method do anything for me besides omit a layer of mapping
? Performance gains ? Other ? It looks looks only a mapping to me.
Linux raw devices, used with disk dirves supporting DMA, allow the data
read from the disk drives to be placed directly in the application's
memory space. This avoids having to copy the data from the kernel space
to the user space. I don't recall seeing anything about direct I/O doing
this. DB2's direct I/O does avoid system caching of the data.
2. "Should I" & "Can I" change the db containers that the current
tablespace references from /dev/raw to /dev/sda.
A redirected restore is capable of relocating containers. If you do this
on the speculation that at some future time raw devices will cease to
exist, then you have a 25% chance of making the right decision. (Will
the feature be removed and is there a performance hit today going from
raw to direct I/O?)
3. If I leave my tablespace containers referencing /dev/raw/raw, then
how do they map to /dev/sda ? I assume that I still require the
issuance of the 'raw' command unless I create a new tablespace.

The 'raw' caommand allows mapping directly to device nodes OR to named
devices such as sda. Since you don't appear to be the system
administrator, you might want to get a peek at /etc/sysconfig/rawdevices
(RHEL4) to see how your system's are defined.

Phil Sherman
May 3 '06 #2

P: n/a
Thank you for your response

May 10 '06 #3

P: n/a
Thank you for your response

May 10 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.