473,903 Members | 4,060 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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 "performanc e 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.de mon.co.uk/spam>
Nov 12 '05
42 4710
I wonder whether it makes the same difference on RAID.

Andy
Jim Smith <ji*@jimsmith.d emon.co.uk> wrote in message news:<dS******* *******@jimsmit h.demon.co.uk>. ..
....
<quote>
raw devices, at least on Solaris, are about 10 times as fast as cooked
file systems for Informix.
<quote>

Nov 12 '05 #11
[cutting]

<quote>
raw devices, at least on Solaris, are about 10 times as fast as cooked
file systems for Informix.
<quote>


Tooooo much, at best I've seen 30%. I'd budget on 10-15%

[cutting]

--
Paul Watson #
Oninit Ltd # Growing old is mandatory
Tel: +44 1436 672201 # Growing up is optional
Fax: +44 1436 678693 #
Mob: +44 7818 003457 #
www.oninit.com #
Nov 12 '05 #12
In message <40************ **********@news .optusnet.com.a u>, Noons
<wi*******@yaho o.com.au> writes
"Jim Smith" <ji*@jimsmith.d emon.co.uk> wrote in message
news:dS******* *******@jimsmit h.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?


None of the above. A faster response and or throughput from a user point
of view.
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!


But it will give a faster response therefore "file systems are faster".

But, database blocks will often be buffered in the db buffer cache so
the file system buffer may be irrelevant or even an overhead. I vaguely
remember on VMS it was recommended you disable disk caching and used
oracle's buffer cache.
--
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.de mon.co.uk/spam>
Nov 12 '05 #13
In message <40************ **********@news-text.dial.pipex .com>, Niall
Litchfield <ni************ **@dial.pipex.c om> writes
"Jim Smith" <ji*@jimsmith.d emon.co.uk> wrote in message
news:dS******* *******@jimsmit h.demon.co.uk.. .
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>

2. Who cares - what matters isn't the speed of the disk read, but the
response time for the end users screens/jobs - if and only iff you can show
that this is slow and the speed is caused by a file system would you
consider RAW.


I didn't really ask about IO performance, I was talking about
application performance.
--
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.de mon.co.uk/spam>
Nov 12 '05 #14
"Dave Hughes" <da*********@wa veform.plus.com > wrote in message
news:xn******** ********@usenet .plus.net...
On 2004-04-13, Mark A scribbled:
Raw disk has the potential for best performance with large tablespace
and index scans in a data warehouse environment. During sequential
prefetch, DB2 can make sure that the extents are contiguous on the
disk if the space is DMS raw disk. It makes no difference for OLTP
systems. Decision support systems that do not frequently use large
tablespace scans, also will show very little benefit. To the extent
that data is already in the buffer pool, it makes no difference.
One other point to note regarding DB2's DMS (Database Managed)
table-spaces is that they don't /have/ to be on raw devices - you can
use file "containers " instead (just a great big file on the file-system
the entire contents of which is managed by DB2). Assuming the file
system has sufficient contiguous space (or you defrag after creating
one) you get the benefit of contiguous data without the complexity of
raw devices.

Though I haven't tried raw devices on DB2, I regularly use DMS
file-based containers and have found them to be noticeably faster than
the default SMS (System Managed) table-spaces (which are mostly
individual files for individual database objects) with queries against
massive tables.

The problem with SMS is that new space is allocated one page at a time. This
can slow down rapidly growing tablspaces. However one can run db2empfa to
have SMS tablespaces allocate one extent at a time.
I'd be interested to know if anyone's directly compared DB2's DMS
table-spaces on raw devices and file system containers. I suspect
there'd be a difference - but I doubt it'd be huge.

IBM has compared them and there is a slight difference when doing tablespace
scans, but almost no difference otherwise. However using file systems
enables OS file caching, which can be a benefit or a hinderance, depending
on who you ask, or what exact situtation is present.

Nov 12 '05 #15
Mark Bole wrote:
I haven't worked with an Oracle raw device since version 7.3 seven
years ago, and would never go back. The administrative overhead is
just too much of a headache.


[Posting from comp.databases. informix]

I've never understood the "administra tive overhead" argument against raw
spaces. Can you elicidate on the administration you think needs to be
applied? In my experience, the only admin overhead is making sure that a
new, naive sysop doesn't try to turn a raw space into a filesystem - I saved
an engine by SECONDS once, by looking over the shoulder of said sysop as I
walked past....

Apart from that, I find that admin is slightly simpler simply because you
don't need to run a mkfs style of command ;-)

I have heard that Solaris (?) is in the habit of re-creating /dev at boot
time, and I know that DG-UX used to do the same thing. Therefore some sort
of tool is needed to make sure the raw devs exist after a boot. Is this what
you mean?
Nov 12 '05 #16
Data Goob wrote:
I've found jfs to be "fast enough", considering we are moving
from SQL-Server, no raw-disks on that one ( chuckles and laughs
allowed :-) . The risks that raw-disks present makes me wonder
if they are worth it. Restoring raw-disk databases presents its
own set of problems, whereas regular files can be backed up and
restored more simply and with more flexibility.


Ummmmm, if you try to archive regular files when the database is active, you
*will* have an inconsistent snapshot of the database. Do you perform these
backups only when the engine is offline? I can't see this being safe on any
brand of engine if the database is "twinkling" . The only way to get a
consistent (ie logical instant in time) backup of a live, active database is
to use a tool which maintains the illusion on your behalf.
Nov 12 '05 #17
Andrew Hamm wrote:

Mark Bole wrote:
I haven't worked with an Oracle raw device since version 7.3 seven
years ago, and would never go back. The administrative overhead is
just too much of a headache.


[Posting from comp.databases. informix]

I've never understood the "administra tive overhead" argument against raw
spaces. Can you elicidate on the administration you think needs to be
applied? In my experience, the only admin overhead is making sure that a
new, naive sysop doesn't try to turn a raw space into a filesystem - I saved
an engine by SECONDS once, by looking over the shoulder of said sysop as I
walked past....

Apart from that, I find that admin is slightly simpler simply because you
don't need to run a mkfs style of command ;-)

I have heard that Solaris (?) is in the habit of re-creating /dev at boot
time, and I know that DG-UX used to do the same thing. Therefore some sort
of tool is needed to make sure the raw devs exist after a boot. Is this what
you mean?


This should only happen with a boot -r, Sun doesn't (used to) guarantee
the
mapping of mulitple external physical devices (A5200, A1000 etc) is
consistent
when boot -r'ing. The 'boot -r' asks what's out there and then assigns
the
devices in the order in which they respond. Mostly it catches lazy
sysadmins,
or sysadmins without larger server experience out. When the disks are
used
with filesystems AFAIK Sun can map the FS back to the disks, I'm
guessing
they use major/minor numbers. Solaris can't do this with the raw disk
'cos Solaris has no idea how they are being used.
--
Paul Watson #
Oninit Ltd # Growing old is mandatory
Tel: +44 1436 672201 # Growing up is optional
Fax: +44 1436 678693 #
Mob: +44 7818 003457 #
www.oninit.com #
Nov 12 '05 #18
Andrew,

Fair enough considerations, and you hit the point on
the head, the backup and restore.

We have always set up backup of logs and data to a real
backup, but considering all the options I might 'need'
in the event of system failure, or migration, or cloning,
raw devices are an added risk. We use a third-party backup
tool to backup our SQL-Server databases, as well as EMC
Timefinder to flash-copy databases into production environments.
We will apply the same methods with DB2 or MySQL for that
matter. The raw-disk paradigm adds only extra trouble/work.

The real question is, how will you backup, much less restore
raw device databases? Are you prepared to deal with the
inflexibility it presents? Have you ever run Informix or
other vendor database through a complete backup and restore,
testing all the options with raw-device dbspaces? Most DBAs
I've run into have never had to restore a database at any
time in their career much less even test it. Is that amazing
or what!

Consider too, clustering of systems and disks, and the
administrative challenges associated with that. Add raw
devices to multitudes of servers and it becomes more risky
and more to manage. It puts more opportunities for failure
in the administration path, and nobody in their right mind
wants to increase risk. Is the extra 10% in speed worth it?
Maybe that 'speed' can come from somewhere else?

One other thing you might find attractive to plain ole files
instead of raw devices is the ability to clone databases. You
can get quite creative with plain files in ways that you cannot
with raw devices because of the lock-in of raw-devices. You
create more work for yourself in the long run with raw disks,
unless of course you're not as lazy as me and actually enjoy
the extra work. '-)

"Andrew Hamm" <ah***@mail.com > wrote in message news:c5******** ****@ID-79573.news.uni-berlin.de...
Data Goob wrote:
I've found jfs to be "fast enough", considering we are moving
from SQL-Server, no raw-disks on that one ( chuckles and laughs
allowed :-) . The risks that raw-disks present makes me wonder
if they are worth it. Restoring raw-disk databases presents its
own set of problems, whereas regular files can be backed up and
restored more simply and with more flexibility.


Ummmmm, if you try to archive regular files when the database is active, you
*will* have an inconsistent snapshot of the database. Do you perform these
backups only when the engine is offline? I can't see this being safe on any
brand of engine if the database is "twinkling" . The only way to get a
consistent (ie logical instant in time) backup of a live, active database is
to use a tool which maintains the illusion on your behalf.


Nov 12 '05 #19

"Data Goob" <da******@hotma il.com> wrote
One other thing you might find attractive to plain ole files
instead of raw devices is the ability to clone databases. You
can get quite creative with plain files in ways that you cannot
with raw devices because of the lock-in of raw-devices.

Please elaborate.

If you use symbolic links for raw devices, then there is no lock-in
of raw devices, or am I missing something.
Nov 12 '05 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.