Cook device vs Raw device 
Author Message
 Cook device vs Raw device
Currently our database data  is stored in cooked chunks. Informix did state
that using raw device is preferably but due to time contraints(other data
was present which required repartitioning the drives) we decided to use
cooked chunks.

I am wondering, how much slower?  Any parameters to set/change when using
cooked chunks to improve the speed ?

Thanks in advance !



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device

All things being equal Raw should be 20%(ish) faster.  Parameters ... whats the platform, what is the OS, what and where are the disks, what sort of volume management are you using,

Paul Watson
WF Software Ltd
Tel: +44 1436 674729
Fax: +44 1436 678729
www.wfsoftware.com/informix
# If you broke it, hide the evidence

Currently our database data  is stored in cooked chunks. Informix did state
that using raw device is preferably but due to time contraints(other data
was present which required repartitioning the drives) we decided to use
cooked chunks.

I am wondering, how much slower?  Any parameters to set/change when using
cooked chunks to improve the speed ?

Thanks in advance !

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they  
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device
Hi Matthew,

When using cooked files you are basically stuck with the overhead of the OS.
The overhead of the OS downgrades performance with Dynamic server mostly due
to the fact that it needs to use the OS in order to store and retrieve data.
This creates a problem if your OS experiences high volume.  The reason is
because like all OS the kernel needs to manage all the activity and
associate it with the correct action to take... much like informix if you
need to write to disk you are depending on the kernel to fork that process
for you. In addition, Informix has no control in how the data is stored on
disk (no contigous order) which is why raw disk devices are used instead.

When using raw disks Informix can optimize its table access and can store
rows of data in a way that Informix likes to do things.  In addition, it
bypasses overhead from your OS (KAIO) if your server supports this feature
of disk I/O and can use direct data transfers from disk to memory and vice
versa.

In some cases such as Linux for example this feature of bypassing IO
overhead does not matter.  The informix server has a built in feature called
Kernel Asynchronous Input Output (KAIO) which is basically your Informix
virtual processor that spawns threads to and from disk (ie. if you need to
write to disk or retrieve data).  This is the feature that allows you to
bypass your server OS disk overhead. Not all platforms have this feature..
most due. In this case however, using either raw disks or cooked files will
not give you any performance advantage.

You can set a few of the disk paramters in your onconfig file. Increase the
number of page cleaners and AIO virtual processors (not KAIO)  to help spawn
more disk threads (make sure that these values are the same). This needs to
be monitored so that you do not eat up to much resources for this feature.
Informix is pretty good in using resources. I like to configure when using
cooked files my AIO and page cleaners to the number of dbspaces I create.
Theoretically, there is a thread for each dbspace that you have created.
You cannot assign a vp to a particular dbspace but it (for me) is a good
method in determining what to set for these parameteres. You can set these
parameters using onmonitor or you can modify your onconfig parameters which
is NUMAIOVPS and CLEANERS.  Make sure that these parameters are identical to
achieve optimum performance.

I hope this explains it a little for you and helps you out.

Lloyd AJ Wilson.

Quote:

>Currently our database data  is stored in cooked chunks. Informix did state
>that using raw device is preferably but due to time contraints(other data
>was present which required repartitioning the drives) we decided to use
>cooked chunks.

>I am wondering, how much slower?  Any parameters to set/change when using
>cooked chunks to improve the speed ?

>Thanks in advance !



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device

Quote:

>Hi Matthew,

>When using cooked files you are basically stuck with the overhead of the
OS.
>The overhead of the OS downgrades performance with Dynamic server mostly
due
>to the fact that it needs to use the OS in order to store and retrieve
data.
>This creates a problem if your OS experiences high volume.  The reason is
>because like all OS the kernel needs to manage all the activity and
>associate it with the correct action to take... much like informix if you
>need to write to disk you are depending on the kernel to fork that process
>for you. In addition, Informix has no control in how the data is stored on
>disk (no contigous order) which is why raw disk devices are used instead.

>When using raw disks Informix can optimize its table access and can store
>rows of data in a way that Informix likes to do things.  In addition, it
>bypasses overhead from your OS (KAIO) if your server supports this feature
>of disk I/O and can use direct data transfers from disk to memory and vice
>versa.

>In some cases such as Linux for example this feature of bypassing IO
>overhead does not matter.  The informix server has a built in feature
called
>Kernel Asynchronous Input Output (KAIO) which is basically your Informix

Just to clarify that these threads work in conjunction with disk and memory.
The threads send and retrieve data to and from memory without going throught
the OS.  I just wanted to clarify this point.

- Show quoted text -

Quote:
>virtual processor that spawns threads to and from disk (ie. if you need to
>write to disk or retrieve data).  This is the feature that allows you to
>bypass your server OS disk overhead. Not all platforms have this feature..
>most due. In this case however, using either raw disks or cooked files will
>not give you any performance advantage.

>You can set a few of the disk paramters in your onconfig file. Increase the
>number of page cleaners and AIO virtual processors (not KAIO)  to help
spawn
>more disk threads (make sure that these values are the same). This needs to
>be monitored so that you do not eat up to much resources for this feature.
>Informix is pretty good in using resources. I like to configure when using
>cooked files my AIO and page cleaners to the number of dbspaces I create.
>Theoretically, there is a thread for each dbspace that you have created.
>You cannot assign a vp to a particular dbspace but it (for me) is a good
>method in determining what to set for these parameteres. You can set these
>parameters using onmonitor or you can modify your onconfig parameters which
>is NUMAIOVPS and CLEANERS.  Make sure that these parameters are identical
to
>achieve optimum performance.

>I hope this explains it a little for you and helps you out.

>Lloyd AJ Wilson.


>>Currently our database data  is stored in cooked chunks. Informix did
state
>>that using raw device is preferably but due to time contraints(other data
>>was present which required repartitioning the drives) we decided to use
>>cooked chunks.

>>I am wondering, how much slower?  Any parameters to set/change when using
>>cooked chunks to improve the speed ?

>>Thanks in advance !



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device

This is a multi-part message in MIME format.
--------------51680D1268E0AE028317D600
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Veritas offer a product - certified for Oracle, however, works just
as well from Informix which allows cooked disk chunks to be used and
returns raw disk performance. The product is Storage Edition with its
Quick I/O database accelerator. The base file system must be VxFS,
however, the offers ease of management when using cooked chunks.

The quick I/O database accelator achieves the significant performance
improvement by presenting a regular file to Informix as a raw
character device. This bypasses traditional UNIX file system overhead
of single writer locks and double buffering - lowering CPU overhead.

Worth a look.

Colin

Quote:

> All things being equal Raw should be 20%(ish) faster.  Parameters ... whats the platform, what is the OS, what and where are the disks, what sort of volume management are you using,

> Paul Watson
> WF Software Ltd
> Tel: +44 1436 674729
> Fax: +44 1436 678729
> www.wfsoftware.com/informix
> # If you broke it, hide the evidence


> Currently our database data  is stored in cooked chunks. Informix did state
> that using raw device is preferably but due to time contraints(other data
> was present which required repartitioning the drives) we decided to use
> cooked chunks.

> I am wondering, how much slower?  Any parameters to set/change when using
> cooked chunks to improve the speed ?

> Thanks in advance !

> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.

> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.

> www.mimesweeper.com
> **********************************************************************

--
--------------51680D1268E0AE028317D600
Content-Type: text/x-vcard; charset=us-ascii;
 name="ctaberma.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Colin Taberman
Content-Disposition: attachment;
 filename="ctaberma.vcf"

begin:vcard
n:Taberman;Colin
tel;cell:+44 (0)370 401 550
tel;fax:+44 (0)870 706 1015
tel;work:+44 (0)181 607 4244
x-mozilla-html:FALSE
url:www.dhl.com
org:DHL Systems Limited;Europe & Africa DataCentre Rationalisation Project
version:2.1

title:Technical Migration Consultant
adr;quoted-printable:;;Kings House=0D=0AGreat West Road;Brentford;Middlesex;TW8 9AU;UK
fn:Colin Taberman
end:vcard

--------------51680D1268E0AE028317D600--



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device

Quote:

> Nothing special you need to do.  You can even bring the
> engine down, copy
> each cooked file to a separate RAW chunk at least as large,
> replace the
> cooked filename with a symbolic link to the RAW file and restart the
> engine.

Art,

is it possible to migrate this way if filesystem files were specified
_without_ offset, but AIX (AFAIK) raw devices must have an offset of a few
kilobytes?

best regards,
ivars

Quote:

> Performance is usually about 8-15% better with RAW chunks over COOKED
> devices and add another 7-10% for filesystem files.  So expect 15-25%
> improvement.

> Art S. Kagel



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device

This is a thread that has always interested me.  I have been reading this
group for awhile, and was concerned when I came to my current place of
employment
and discovered they were using filesystems to hold data.  When we
got the oppurtunity to do some limited testing on raw vs cooked we
could only find at most a  1.5% difference between informix's performance
to raw disk vs. cooked.
We watched the following things:
  iostat,
  vmstat
  wall time

We were running AIX 4.3.2 on a 520
Informix 7.31UC2

Only 2 disk drives, one of which was dedicated to informix data.
Under 2 Gigabytes of data in the whole database

These processes were simple queries(no more than three tables joined)
and the loading of data into tables.

The longest running process was somewhere around 15 minutes.
The processes tested caused the system to be heavily io bound for some
and CPU for others.

From reading the newsgroup I got the impression that I could count on at least
a 10% difference between cooked and raw, yet the tests I ran did not turn out
that way.

The data involved was literally identical.  I was curious what factors might
be causing the performance not to increase.

Will

------------------------------------------------------------
This e-mail has been sent to  you  courtesy of OperaMail,  a
free  web-based  service  from  Opera  Software,  makers  of
the award-winning Web Browser - http://www.operasoftware.com
------------------------------------------------------------



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device
One thing to remember is that the 10%-20% spead improvement is on the actual
disk I/O.

IDS systems with good cache hit rates will not notice much of an improvement
based on
clock time since it uses RAM mostly.

S.W.


Quote:

> This is a thread that has always interested me.  I have been reading this
> group for awhile, and was concerned when I came to my current place of
> employment
> and discovered they were using filesystems to hold data.  When we
> got the oppurtunity to do some limited testing on raw vs cooked we
> could only find at most a  1.5% difference between informix's performance
> to raw disk vs. cooked.
> We watched the following things:
>   iostat,
>   vmstat
>   wall time

> We were running AIX 4.3.2 on a 520
> Informix 7.31UC2

> Only 2 disk drives, one of which was dedicated to informix data.
> Under 2 Gigabytes of data in the whole database

> These processes were simple queries(no more than three tables joined)
> and the loading of data into tables.

> The longest running process was somewhere around 15 minutes.
> The processes tested caused the system to be heavily io bound for some
> and CPU for others.

> From reading the newsgroup I got the impression that I could count on at
least
> a 10% difference between cooked and raw, yet the tests I ran did not turn
out
> that way.

> The data involved was literally identical.  I was curious what factors
might
> be causing the performance not to increase.

> Will

> ------------------------------------------------------------
> This e-mail has been sent to  you  courtesy of OperaMail,  a
> free  web-based  service  from  Opera  Software,  makers  of
> the award-winning Web Browser - http://www.operasoftware.com
> ------------------------------------------------------------



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device

Quote:

> Currently our database data  is stored in cooked chunks. Informix did state
> that using raw device is preferably but due to time contraints(other data
> was present which required repartitioning the drives) we decided to use
> cooked chunks.

> I am wondering, how much slower?  Any parameters to set/change when using
> cooked chunks to improve the speed ?

Nothing special you need to do.  You can even bring the engine down, copy
each cooked file to a separate RAW chunk at least as large, replace the
cooked filename with a symbolic link to the RAW file and restart the
engine.

Performance is usually about 8-15% better with RAW chunks over COOKED
devices and add another 7-10% for filesystem files.  So expect 15-25%
improvement.

Art S. Kagel



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device

Correct if I'm wrong (I'm sure someone will :), but I always thought that
raw disk only really starts giving you performance gains when it comes to
doing lots of writes. Given this, the 1.5% gained below was due to the
marginal performance gain from not having to go thru the block device
interface for reads. Conversely, if William tried the test again, this time
doing inserts/updates/deletes, he'll see very much improved figures.

Andrew Reardon
UNIX/Informix Administrator
AeroSpace Support, Boeing Australia Ltd.
Ph: +61 7 3306 3346 Mob: +61 0419 745 831

Quote:
> ----------

> Sent:      Thursday, September 16, 1999 6:01 AM
> To:        William Rice
> Cc:        informix-list
> Subject:   RE: Cook device vs Raw device

> This is a thread that has always interested me.  I have been reading this
> group for awhile, and was concerned when I came to my current place of
> employment
> and discovered they were using filesystems to hold data.  When we
> got the oppurtunity to do some limited testing on raw vs cooked we
> could only find at most a  1.5% difference between informix's performance
> to raw disk vs. cooked.
> We watched the following things:
>   iostat,
>   vmstat
>   wall time

> We were running AIX 4.3.2 on a 520
> Informix 7.31UC2

> Only 2 disk drives, one of which was dedicated to informix data.
> Under 2 Gigabytes of data in the whole database

> These processes were simple queries(no more than three tables joined)
> and the loading of data into tables.

> The longest running process was somewhere around 15 minutes.
> The processes tested caused the system to be heavily io bound for some
> and CPU for others.

> From reading the newsgroup I got the impression that I could count on at
> least
> a 10% difference between cooked and raw, yet the tests I ran did not turn
> out
> that way.

> The data involved was literally identical.  I was curious what factors
> might
> be causing the performance not to increase.

> Will

> ------------------------------------------------------------
> This e-mail has been sent to  you  courtesy of OperaMail,  a
> free  web-based  service  from  Opera  Software,  makers  of
> the award-winning Web Browser - http://www.operasoftware.com
> ------------------------------------------------------------



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device

Quote:

> > Nothing special you need to do.  You can even bring the
> > engine down, copy
> > each cooked file to a separate RAW chunk at least as large,
> > replace the
> > cooked filename with a symbolic link to the RAW file and restart the
> > engine.

> Art,

> is it possible to migrate this way if filesystem files were specified
> _without_ offset, but AIX (AFAIK) raw devices must have an offset of a few
> kilobytes?

> best regards,
> ivars

> > Performance is usually about 8-15% better with RAW chunks over COOKED
> > devices and add another 7-10% for filesystem files.  So expect 15-25%
> > improvement.

> > Art S. Kagel

Hi Ivars,

there is no absolute need to have an offset when raw devices in AIX, although
it is better to specify an offset of 4 k.

AIX stores some information about the logical volume in the first 512 (maybe
1024 ?) bytes of a logical volume. But it also checks if this area has been
overwritten. If yes, it disregards the AIX information that usually is there,
but does not try to restore it. So, you just miss some information when
looking at the logical volume characteristics. At least that's the theory (and
in most cases it works).

Regards
--
Helmut Leininger

Bull AG / Vienna
Open Systems Support



This opinion is mine and not necessarily that of my employer.
No guarantees whatsoever.



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device

Quote:

> This is a thread that has always interested me.  I have been reading this
> group for awhile, and was concerned when I came to my current place of
> employment
> and discovered they were using filesystems to hold data.  When we
> got the oppurtunity to do some limited testing on raw vs cooked we
> could only find at most a  1.5% difference between informix's performance
> to raw disk vs. cooked.
> We watched the following things:
>   iostat,
>   vmstat
>   wall time

> We were running AIX 4.3.2 on a 520
> Informix 7.31UC2

> Only 2 disk drives, one of which was dedicated to informix data.
> Under 2 Gigabytes of data in the whole database

> These processes were simple queries(no more than three tables joined)
> and the loading of data into tables.

> The longest running process was somewhere around 15 minutes.
> The processes tested caused the system to be heavily io bound for some
> and CPU for others.

> From reading the newsgroup I got the impression that I could count on at least
> a 10% difference between cooked and raw, yet the tests I ran did not turn out
> that way.

> The data involved was literally identical.  I was curious what factors might
> be causing the performance not to increase.

> Will

> ------------------------------------------------------------
> This e-mail has been sent to  you  courtesy of OperaMail,  a
> free  web-based  service  from  Opera  Software,  makers  of
> the award-winning Web Browser - http://www.operasoftware.com
> ------------------------------------------------------------

Hi Will,

Although I am a fan of using rwa devices for several reasons (among them speed, no
accessability by "normal" Unix tools like cpio, rm, ...) I think your impression
maybe right. AIX has a rather good caching mechanism for file systems (some people
characterise it as "use all free memory for file system cache" or "the file system
is just an extension of the memory") that will "hide" quite a lot of the
performance difference between file systems and raw devices.

Regards
--
Helmut Leininger

Bull AG / Vienna
Open Systems Support



This opinion is mine and not necessarily that of my employer.
No guarantees whatsoever.



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device

How are you accessing the raw device, as a raw disk or a raw logical volume.  As a raw logical volume all access must be in 512 byte blocks or it'll run very poorly.  If it is as a real raw disk there should be no other logical volumes on any part of the disk.

You might like to check the min/max servers side of AIO.

Are you using IBM disks, if not then changing the q_type to simple and alternating the queue_depth to 3 should help

IBM provide a performance package makes life a lot easier, the one on the OS distribution is incorrect, you need to get the correct one from the IBM web site ( I think it's the Austen one).  If you can't find it come back to me I'll send the copy over and a couple of data collection scripts.

Rather than using iostat you need to be using filemon, it give a much more detailed breakdown of what is going on.

Paul Watson
WF Software Ltd
Tel: +44 1436 674729
Fax: +44 1436 678729
www.wfsoftware.com/informix
# If you broke it, hide the evidence

This is a thread that has always interested me.  I have been reading this
group for awhile, and was concerned when I came to my current place of
employment
and discovered they were using filesystems to hold data.  When we
got the oppurtunity to do some limited testing on raw vs cooked we
could only find at most a  1.5% difference between informix's performance
to raw disk vs. cooked.
We watched the following things:
  iostat,
  vmstat
  wall time

We were running AIX 4.3.2 on a 520
Informix 7.31UC2

Only 2 disk drives, one of which was dedicated to informix data.
Under 2 Gigabytes of data in the whole database

These processes were simple queries(no more than three tables joined)
and the loading of data into tables.

The longest running process was somewhere around 15 minutes.
The processes tested caused the system to be heavily io bound for some
and CPU for others.

From reading the newsgroup I got the impression that I could count on at least
a 10% difference between cooked and raw, yet the tests I ran did not turn out
that way.

The data involved was literally identical.  I was curious what factors might
be causing the performance not to increase.

Will

------------------------------------------------------------
This e-mail has been sent to  you  courtesy of OperaMail,  a
free  web-based  service  from  Opera  Software,  makers  of
the award-winning Web Browser - http://www.operasoftware.com
------------------------------------------------------------

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they  
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device

For raw disk, paging cache and the pagin mechanism are not used, the data is read or written directly between the device and the user address space.  Therefore raw disk aviods the need to copy between kernel address space and user address space. This means that both reads and writes should seem the same performance improvement (ignoring the fancy write algorithms and pre-fetch algorithms etc). But as someone else pointed out if your buffer rates are high then the reads will not be going to disk, so you'll see the more benefits on writes.  

Paul Watson
WF Software Ltd
Tel: +44 1436 674729
Fax: +44 1436 678729
www.wfsoftware.com/informix
# If you broke it, hide the evidence

Correct if I'm wrong (I'm sure someone will :), but I always thought that
raw disk only really starts giving you performance gains when it comes to
doing lots of writes. Given this, the 1.5% gained below was due to the
marginal performance gain from not having to go thru the block device
interface for reads. Conversely, if William tried the test again, this time
doing inserts/updates/deletes, he'll see very much improved figures.

Andrew Reardon
UNIX/Informix Administrator
AeroSpace Support, Boeing Australia Ltd.
Ph: +61 7 3306 3346 Mob: +61 0419 745 831

Quote:
> ----------

> Sent:      Thursday, September 16, 1999 6:01 AM
> To:        William Rice
> Cc:        informix-list
> Subject:   RE: Cook device vs Raw device

> This is a thread that has always interested me.  I have been reading this
> group for awhile, and was concerned when I came to my current place of
> employment
> and discovered they were using filesystems to hold data.  When we
> got the oppurtunity to do some limited testing on raw vs cooked we
> could only find at most a  1.5% difference between informix's performance
> to raw disk vs. cooked.
> We watched the following things:
>   iostat,
>   vmstat
>   wall time

> We were running AIX 4.3.2 on a 520
> Informix 7.31UC2

> Only 2 disk drives, one of which was dedicated to informix data.
> Under 2 Gigabytes of data in the whole database

> These processes were simple queries(no more than three tables joined)
> and the loading of data into tables.

> The longest running process was somewhere around 15 minutes.
> The processes tested caused the system to be heavily io bound for some
> and CPU for others.

> From reading the newsgroup I got the impression that I could count on at
> least
> a 10% difference between cooked and raw, yet the tests I ran did not turn
> out
> that way.

> The data involved was literally identical.  I was curious what factors
> might
> be causing the performance not to increase.

> Will

> ------------------------------------------------------------
> This e-mail has been sent to  you  courtesy of OperaMail,  a
> free  web-based  service  from  Opera  Software,  makers  of
> the award-winning Web Browser - http://www.operasoftware.com
> ------------------------------------------------------------

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they  
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************



Wed, 18 Jun 1902 08:00:00 GMT
 Cook device vs Raw device

This is a response to the messages I have read so far.

One of the loads took around 15 minutes. During which time
we were completely i/o bound.  I will admit, the disk was
over 96% usage the whole time.  So maybe we could not see the difference in
performance due to the fact the disk was pretty much pegged either way.

We were going to the raw character device.

We do have a good cache rate on our machines.
It is difficult for me to justify the time and resources my company will have
to
use to go to raw disk space if I can not show how making this change
will benefit the company.

Previously when on raw spaces this company had issues
with informix not handling remappable i/o errors as well as the AIX operating
system does.  It caused the chunk to go offline, and the options offered by
informix I believe were let them dial in to fix it or do a restore.  When
running
on filesystems they have not experienced such issues.(I was not here at
the point in time this occurred so do not have the specifics of what occurred)

Given what I have seen so far, I understand and agree with my current
employers recluctance to go to raw disk.  This is not a testimonial against
raw disk space.  It is a statement that for the system we run I have not seen
a case which can be build for going to raw disk.  I opened this question up
because somewhere deep in my gut I feel raw disk has to be a good bit faster
because you are bypassing the operating systems buffering(This is probably
due to reading lots of Art Kagel postings)  But my gut is by no means
justification.  Just that from what they have seen, for their situation
raw disk space does not seem to have much of a performance benefit, and
has in the past caused parts of the business to be offline.

Will

------------------------------------------------------------
This e-mail has been sent to  you  courtesy of OperaMail,  a
free  web-based  service  from  Opera  Software,  makers  of
the award-winning Web Browser - http://www.operasoftware.com
------------------------------------------------------------



Wed, 18 Jun 1902 08:00:00 GMT
 
 [ 21 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Cook device vs. Raw device

2. Cooked files vs raw devices

3. Raw vs. cooked devices

4. Raw Device Vs.Cooked File

5. Raw devices Vs. File system devices

6. raw device or not raw device

7. Informix/AIX block raw device to character raw device

8. Cooked verses raw devices and dsync

9. Raw vrs Cooked device

10. Red Hat 7.2 : Ext3 cooked file system versus raw devices

11. Raw I/O vs files (was Re: Raw partitions / cooked files)

12. DISK DEVICE vs TAPE DEVICE BACKUP


 
Powered by phpBB® Forum Software