f



Re: Raw vs. Cooked files #2

Hi,

I'd say the correct answer to the question is:
"It depends."

--------------------------------------------------------------------
The implementation of file system I/O buffering by the
OS can be very efficient on Linux. But for that the OS
needs sufficient memory for the buffering. And this is
what makes the "It depends".

Therefore there are 2 extremes:

a) almost all physical memory is used by IDS in the
  form of shared memory (allocated SHM segments
  listed by "onstat -g seg"). A good indication for this
  scenario is a machine that uses little swap space,
  because it already has swapped out some minor
  "applications". The system is at the (sensible) limit
  of its memory usage.

  In this scenario, raw devices and the utilization of
  KAIO (available with IDS 10.00.UC1 on Linux) will
  in general perform better than cooked files.

b) there's a lot of unused physical memory left over,
  even though IDS is configured optimally (e.g.
  BUFFERS is big enough, etc.). A recent example
  of such a scenario was 32-bit IDS installed on a
  64-bit Linux, where IDS can use only ~4 GB of the
  available 24 GB of physical memory. In such a
  scenario, the OS can allocate a lot of memory for
  file system I/O buffering and this will make file
  system I/O (i.e. for chunks on cooked files) very
  efficient. In this scenario it will normally perform
  better than raw devices and KAIO.

This is the general experience on Linux, where
cooked file chunks are on a non-journalling file
system. Not all journalling file systems are un-suitable
for IDS chunks, but "reiserfs" certainly is un-suitable,
so make sure you stay clear of that. E.g. use the
"ext2" file system instead.

Unix flavours other than Linux may exhibit completely
different behaviour regarding raw devices vs. cooked
files. This is mainly because they use different
implementations of file systems and their I/O buffering.
These things cannot be compared across different
operating systems.
--------------------------------------------------------------------

I think I've written an e-mail to this effect before to this
list, but I'm not sure.

So whoever feels responsible for some certain FAQ
pages, please feel free to cut&paste the above text
between the "---------" separators into the FAQ (with or
without citing my name ...). But make sure that the text
is complete !

Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

owner-informix-list@iiug.org wrote on 18.05.2005 00:40:08:
> Rajesh Kapur wrote:
> > Hello,
> 
> Chec out last weeks postings here where this subject was beaten to 
death.  I 
> say YES!  Others say NO!  Bottom line?  Test it yourself.  The article 
you 
> quote in the FAQ tells you how I tested it.
> 
> Art S. Kagel
> 
> > I am installing IDS 10 on RHEL3 on an intel x86 server. I need to make 
the 
> > choice between raw devices and cooked files.
> > I found the following information in the FAQ's. Is this information 
still 
> > accurate? Do cooked files continue to be significantly slower than the 
raw 
> > files? I have heard that UNIX file systems have improved over the 
years and 
> > the performance divide between raw and cooked files has narrowed 
> > considerabley. Is it true?
> > 
> > Thanks!
> > - Rajesh
> > 
--------------------------------------------------------------------------------------
> > 
> > 6.38 Is raw disk faster than cooked files?
> > On 22nd Jun 1998 kagel@bloomberg.net (Art S. Kagel) wrote:-
> > 
> > ....................the safety issue of cooked files is no longer a 
problem. 
> > The big problem with cooked files still is performance. All writes and 
reads 
> > to/from cooked files MUST go through the UNIX buffer cache. This means 
an 
> > additional copy from the server's output buffer to the UNIX buffer 
page then 
> > a synchronous write to disk. This is opposed to a write to a way file 
where 
> > the server's output buffer is written directly to disk without the 
> > intervening copy. This is just faster. Anyone who has written anything 
that 
> > can test this can attest to the difference in speed. Here are my test 
> > results:
> > 
> > 
> > FileType   Sync?   Times (real/user/system) 2run avg
> > ---------------   -----   -----------------------------------------
> > Filesystem file     N     14.40/3.70/2.52
> >         Y   15.02/3.61/2.63
> > Cooked disk     N   12.81/3.74/2.24
> >         Y   13.42/3.84/2.43
> > Raw disk     N    9.32/3.67/1.52
> >         Y    9.40/3.66/1.44
> > 
> > From this you can clearly see the cost of Cooked files and of synced 
cooked 
> > files. The tests were done with a version of my ul.ec utility modified 
to 
> > optionally open the output file O_SYNC. Cooked disk partition is 
almost 50% 
> > slower than raw disk partition and cooked filesystem files are almost 
60% 
> > slower. The penalty for O_SYNC is an additional 5% for cooked files 
and 
> > negligible for RAW files (as expected). The test file was 2.85MB 
written 
> > using 4K I/O pages (the default fopen application buffer size) which 
should 
> > simulate Informix performance. The Cooked and Raw disk partition tests 
were 
> > conducted to a singleton 9GB Fast Wide SCSI II drive using the raw and 

> > cooked device files corresponding to the same drive.
> > 
> > 

sending to informix-list
0
Martin
5/18/2005 8:27:07 AM
comp.databases.informix 16083 articles. 0 followers. Post Follow

2 Replies
339 Views

Similar Articles

[PageSpeed] 17

Martin Fuerderer wrote:
> Hi,

I emailed a simple response yesterday, but the link seems to be lost. 
Here's another more detailed one:

It does not matter HOW much memory the OS has for a buffer cache.  There are 
still several reasons why RAW will ALWAYS be faster than COOKED devices or 
OS filesystem files:

1) If the OS cache is too small bulk server IO like checkpoints and peak 
load LRU flushing will thrash the cache killing OS and server performance. 
- Thanks for pointing that out Jake.

2) All IO to a COOKED device or FS file MUST first be copied from the IDS 
buffers to the OS buffers before the actual IO operation.  This MUST be 
extra overhead not needed on a RAW device - by definition!

3) If you are writing to an FS file chunk instead of a COOKED device you 
have the additional overhead of the filesystem and directory and inode 
maintenance.  While so called 'fast filesystems' reduce these particular 
overhead items they can do nothing to eliminate it or to eliminate the 
effects of #2!

4) The cache buys you nothing for writing because IDS correctly opens all 
COOKED chunks in O_SYNC mode which means that the buffer is immediately 
flushed to disk as soon as it is copied from the IDS buffer and IDS still 
has to wait for this write to complete as it does for RAW.  However, for RAW 
  IDS does not have to wait for the second buffer copy.

5) On the read side, it's counterintuitive, but, there is little gained from 
the OS cache.  Why?  Reasons:
     - Everything that IDS needs is already in its own cache and also in the 
SAN cache and also on the disk drives' caches!  You're just adding one more 
redundant cache!
     - Each block read has to be copied first to the OS buffer cache before 
it can be handed to IDS if it's not already in OS cache.  Raw doesn't have 
this overhead.
     - Because IDS's cache management is RDBMS behavior specific, chances 
are if a page is in the OS cache, then it's already in the IDS cache and 
will never be read from OS cache again.  Is this redundant to the first 
point?  Maybe but so is the OS cache ;-) [OK cheap shot.  Back to serious 
points...]

6) Filesystem file chunks will be fragmented on disk and not contiguous like 
COOKED device chunks and RAW chunks.  Some filesystems are better than 
others at reducing file fragmentation, but none are perfect.

You state that on Linux with lots of cache you find AIO to FS files will 
outperform KAIO on RAW device.  Prove it Martin.  I posted my test results, 
post yours (and don't forget to post O_SYNC #'s if you are using a direct to 
disk test as I did rather than a DB timing -- admittedly difficult to time 
accurately which is why I use a direct-to-disk test).  My test was performed 
using my ul.ec utility to read a large IDS table writting to disk files, raw 
and cooked devices using the identical query with and without the -U flag to 
enable/disable O_SYNC IO (with -U is how IDS does it, but I was curious what 
the real cost of that O_SYNC setting was).  A pre-test run of ul.ec with the 
same query primed the cache of whatever records would be likely to remain 
after a completed run.  The source for ul.ec is in my utils2_ak package in 
the IIUG Repository, so you can repeat that test or devise your own.

Art S. Kagel

> I'd say the correct answer to the question is:
> "It depends."
> 
> --------------------------------------------------------------------
> The implementation of file system I/O buffering by the
> OS can be very efficient on Linux. But for that the OS
> needs sufficient memory for the buffering. And this is
> what makes the "It depends".
> 
> Therefore there are 2 extremes:
> 
> a) almost all physical memory is used by IDS in the
>   form of shared memory (allocated SHM segments
>   listed by "onstat -g seg"). A good indication for this
>   scenario is a machine that uses little swap space,
>   because it already has swapped out some minor
>   "applications". The system is at the (sensible) limit
>   of its memory usage.
> 
>   In this scenario, raw devices and the utilization of
>   KAIO (available with IDS 10.00.UC1 on Linux) will
>   in general perform better than cooked files.
> 
> b) there's a lot of unused physical memory left over,
>   even though IDS is configured optimally (e.g.
>   BUFFERS is big enough, etc.). A recent example
>   of such a scenario was 32-bit IDS installed on a
>   64-bit Linux, where IDS can use only ~4 GB of the
>   available 24 GB of physical memory. In such a
>   scenario, the OS can allocate a lot of memory for
>   file system I/O buffering and this will make file
>   system I/O (i.e. for chunks on cooked files) very
>   efficient. In this scenario it will normally perform
>   better than raw devices and KAIO.
> 
> This is the general experience on Linux, where
> cooked file chunks are on a non-journalling file
> system. Not all journalling file systems are un-suitable
> for IDS chunks, but "reiserfs" certainly is un-suitable,
> so make sure you stay clear of that. E.g. use the
> "ext2" file system instead.
> 
> Unix flavours other than Linux may exhibit completely
> different behaviour regarding raw devices vs. cooked
> files. This is mainly because they use different
> implementations of file systems and their I/O buffering.
> These things cannot be compared across different
> operating systems.
> --------------------------------------------------------------------
> 
> I think I've written an e-mail to this effect before to this
> list, but I'm not sure.
> 
> So whoever feels responsible for some certain FAQ
> pages, please feel free to cut&paste the above text
> between the "---------" separators into the FAQ (with or
> without citing my name ...). But make sure that the text
> is complete !
> 
> Regards,
> Martin
<Previous SNIPPED>
0
Art
5/19/2005 2:43:23 PM
Art S. Kagel schrieb:
> Martin Fuerderer wrote:
> 
>> Hi,
> 
> 
> I emailed a simple response yesterday, but the link seems to be lost. 
> Here's another more detailed one:
> 
> It does not matter HOW much memory the OS has for a buffer cache.  There 
> are still several reasons why RAW will ALWAYS be faster than COOKED 
> devices or OS filesystem files:
> 
> 1) If the OS cache is too small bulk server IO like checkpoints and peak 
> load LRU flushing will thrash the cache killing OS and server 
> performance. - Thanks for pointing that out Jake.
> 
> 2) All IO to a COOKED device or FS file MUST first be copied from the 
> IDS buffers to the OS buffers before the actual IO operation.  This MUST 
> be extra overhead not needed on a RAW device - by definition!
> 
> 3) If you are writing to an FS file chunk instead of a COOKED device you 
> have the additional overhead of the filesystem and directory and inode 
> maintenance.  While so called 'fast filesystems' reduce these particular 
> overhead items they can do nothing to eliminate it or to eliminate the 
> effects of #2!
> 
> 4) The cache buys you nothing for writing because IDS correctly opens 
> all COOKED chunks in O_SYNC mode which means that the buffer is 
> immediately flushed to disk as soon as it is copied from the IDS buffer 
> and IDS still has to wait for this write to complete as it does for 
> RAW.  However, for RAW  IDS does not have to wait for the second buffer 
> copy.
> 
> 5) On the read side, it's counterintuitive, but, there is little gained 
> from the OS cache.  Why?  Reasons:
>     - Everything that IDS needs is already in its own cache and also in 
> the SAN cache and also on the disk drives' caches!  You're just adding 
> one more redundant cache!
>     - Each block read has to be copied first to the OS buffer cache 
> before it can be handed to IDS if it's not already in OS cache.  Raw 
> doesn't have this overhead.
>     - Because IDS's cache management is RDBMS behavior specific, chances 
> are if a page is in the OS cache, then it's already in the IDS cache and 
> will never be read from OS cache again.  Is this redundant to the first 
> point?  Maybe but so is the OS cache ;-) [OK cheap shot.  Back to 
> serious points...]
> 
> 6) Filesystem file chunks will be fragmented on disk and not contiguous 
> like COOKED device chunks and RAW chunks.  Some filesystems are better 
> than others at reducing file fragmentation, but none are perfect.
> 
> You state that on Linux with lots of cache you find AIO to FS files will 
> outperform KAIO on RAW device.  Prove it Martin.  I posted my test 
> results, post yours (and don't forget to post O_SYNC #'s if you are 
> using a direct to disk test as I did rather than a DB timing -- 
> admittedly difficult to time accurately which is why I use a 
> direct-to-disk test).  My test was performed using my ul.ec utility to 
> read a large IDS table writting to disk files, raw and cooked devices 
> using the identical query with and without the -U flag to enable/disable 
> O_SYNC IO (with -U is how IDS does it, but I was curious what the real 
> cost of that O_SYNC setting was).  A pre-test run of ul.ec with the same 
> query primed the cache of whatever records would be likely to remain 
> after a completed run.  The source for ul.ec is in my utils2_ak package 
> in the IIUG Repository, so you can repeat that test or devise your own.

Art, this is all corresponding to my findings.

Still, when using a 32bit IFX engine in a 64bit OS
it can pay off - if you have tons of memory and if one cannot
upgrade to a 64bit IFX version - to put tables with high READ
access rate onto cooked files. Only so much that the OS is able to
cache them in the memory not seen by IFX because of the 32bit addrspace
limitations.

Dic_k


[ ... snipped ... (to hide the TOFU style posting) ... ]

-- 
Richard Kofler
SOLID STATE EDV
Dienstleistungen GmbH
Vienna/Austria/Europe
0
Richard
5/20/2005 6:27:11 PM
Reply:

Similar Artilces:

Re: raw vs. cooked files under linux #2
Dear Heinz, I would suggest that you pick SUSE SLES 9 This SUSE version works perfectly with IDS 10. Please check the following link: http://www-306.ibm.com/software/data/informix/linux/ids.html With IDS 10 you have the freedom of choice to use cooked or raw devices with KAIO This link should answer your raw device support question http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0503szabo/?ca=dgr-lnxw41IDSTen Let me know if you have any additional questions. bye Sandor IBM Informix Development Munich Information Management Hollerithstra�e 1 81829 Munich Germany Phone: +49 89 4504 1429 "Heinz Weitkamp" <heinz.weitkamp@w estfleisch.de> To Sent by: "user-group Informix \(E-Mail\)" owner-informix-li <informix-list@iiug.org> st@iiug.org cc Subject 11.05.2005 10:48 raw vs. cooked files under linux ...

Re: Measurements: (was: Raw vs. Cooked files) #2
Hi, > Why is NOAGE set to 0? Surely it should be set to 1? For this work the machine was dedicated solely to IDS server. No other applcations were running on the machine. Therefore NOAGE 1 vs. 0 would not have made much of a difference as there were no other processes to compete with IDS for CPU-time. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management owner-informix-list@iiug.org wrote on 29.06.2005 02:32:39: > > Nice but.... > > Can we get this done with IDS 10? > > Set RESIDENT to -1 to make everything resident. > > Why is NOAGE set to 0? Surely it should be set to 1? > > > Martin Fuerderer wrote: > > Hi, > > > > if you are interested : > > > > http://www.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130667.pdf > > > > (There's a part where they tested raw devices vs. file system files as > > well. > > These measurements were all done on zSeries, not by myself as I did not > > get to do such extensive work. But this document is really extensive ....) > > > > Regards, > > Martin > > -- > > Martin Fuerderer > > IBM Informix Development Munich, Germany > > Information Management > > > sending to informix-list Martin Fuerderer schrieb: > Hi, > > >>Why is NOAGE set to 0? Surely i...

Re: Raw vs. Cooked files
Yes even with DB2 UDB you can get 20-25% improvement going with RAW over Cooked. If you use cooked the IO has to be written by the Unix Operating system - another set of commands to execute. Raw is controlled by the database. Why o Why Are we still having this discussion? Rob Vorbroker --- Rajesh Kapur <rkapur@mpr.org> wrote: > Hello, > > I am installing IDS 10 on RHEL3 on an intel x86 > server. I need to make the > choice between raw devices and cooked files. > I found the following information in the FAQ's. Is > this information still > accurate? Do cooked files continue to be > significantly slower than the raw > files? I have heard that UNIX file systems have > improved over the years and > the performance divide between raw and cooked files > has narrowed > considerabley. Is it true? > > Thanks! > - Rajesh > -------------------------------------------------------------------------------------- > > 6.38 Is raw disk faster than cooked files? > On 22nd Jun 1998 kagel@bloomberg.net (Art S. Kagel) > wrote:- > > ....................the safety issue of cooked files > is no longer a problem. > The big problem with cooked files still is > performance. All writes and reads > to/from cooked files MUST go through the UNIX buffer > cache. This means an > additional copy from the server's output buffer to > the UNIX buffe...

Re: raw vs. cooked files under linux
SCO -> Linux ... good ;) If you want to upgrade to IDS 10.0 then better use Suse 9 'cause IDS use Kernel 2.6 specific features like KAIO. There is a nice document on IDS 10 and Linux on IBM site (can't remember link...). Regarding cooked vs. raw devices O bet for raw devices, they are very easy to configure in linux and give you some benefits like KAIO for example. J. Heinz Weitkamp escribi�: > Hi all, > > i am an linux newbie. > I must shift our Databases from SCO Unix (IDS 7.31 UD4) to SuSE Linux > Enterprise Edition 8.1 (2.4.21-190-smp glibc 2.2.5) or (8.2) or 9 and SuSE > Linux Professional 9.3 (2.6.11.4 glibc 2.3.4) (IDS 7.31 UD8). > > Later on i want to upgrade (in place) to IDS 10.0. > Which Version of SuSE Linux Enterprise Edition must I use (8.? , 9 ..)? > > Under Sco Unix we use raw-devices. > Is it better to use cooked files or raw files under these Linux-Versions? > A colleague mentioned, it can be, that later releases of Linux don't support > raw-devices. Is that correct? > > Experiences or comments are welcome. > Thanks in advance. > (Excuse my poor school-english) > > Heinz > > sending to informix-list > sending to informix-list ...

Re: Measurements: (was: Raw vs. Cooked files)
Hi, maybe. :) This work was done by zSeries people (which are in a different department/organization from us in IBM Informix Data Management ...). They used IDS mainly for their purpose (to show zLinux capabilities like scaling with a real, commercially available application). Therefore we cannot directly demand from them to do this again with IDS 10.00. However, there is a possibility, that for their next round of measurements they will use IDS 10.00 (as they made good experiences with IDS 9.4). Though in that case I would not expect results before sometime next year .... Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management owner-informix-list@iiug.org wrote on 29.06.2005 02:31:50: > > Can we get this done with IDS 10? > > Martin Fuerderer wrote: > > Hi, > > > > if you are interested : > > > > http://www.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130667.pdf > > > > (There's a part where they tested raw devices vs. file system files as > > well. > > These measurements were all done on zSeries, not by myself as I did not > > get to do such extensive work. But this document is really extensive ....) > > > > Regards, > > Martin > > -- > > Martin Fuerderer > > IBM Informix Development Munich, Germany > > Information Management sending to i...

Re: Raw vs. Cooked files #3
HOWEVER, Informix IDS does not user the OS buffering. It opens all COOKED chunks with O_SYNC which bypasses most of the benefits of the buffering in favor of added data integrity. Art S. Kagel ----- Original Message ----- From: Martin Fuerderer <MARTINFU@de.ibm.com> At: 5/18 4:27 Hi, I'd say the correct answer to the question is: "It depends." -------------------------------------------------------------------- The implementation of file system I/O buffering by the OS can be very efficient on Linux. But for that the OS needs sufficient memory for the buffering. And this is what makes the "It depends". Therefore there are 2 extremes: a) almost all physical memory is used by IDS in the form of shared memory (allocated SHM segments listed by "onstat -g seg"). A good indication for this scenario is a machine that uses little swap space, because it already has swapped out some minor "applications". The system is at the (sensible) limit of its memory usage. In this scenario, raw devices and the utilization of KAIO (available with IDS 10.00.UC1 on Linux) will in general perform better than cooked files. b) there's a lot of unused physical memory left over, even though IDS is configured optimally (e.g. BUFFERS is big enough, etc.). A recent example of such a scenario was 32-bit IDS installed on a 64-bit Linux, where IDS can use only ~4 GB of the ava...

Re: raw vs. cooked files under linux #8
How does one use O_SYNC with and ext3 filesystem on Linux? I don't see it mentioned anywhere. Normally I use raw but SA and management would rather use cooked. They would also rather use Postgres but that another story. Thanks >You assert that cooked files are as fast today as RAW on SANs. Have YOU >tested it? Are you comparing RAW to COOKED with O_SYNC? Or are you >depending on the vendor stats? Not me, not with my reputation, user >satisfaction, and my job at stake. > > sending to informix-list Peter J Diaz de Leon wrote: > How does one use O_SYNC with and ext3 filesystem on Linux? I don't see > it mentioned anywhere. Normally I use raw but SA and management > would rather use cooked. They would also rather use Postgres but that > another story. > Probably the same way one does for any filesystem, by adding the O_SUNC flag to the oflag argument to the open() system call. So: out_handle = open( "/myfs/mychunkfile", O_WRONLY | O_SYNC ); But isn't ext3 a journaled filesystem? One would first off, not want to use a journaled filesystem for IDS chunks for several reasons: 1- Performance, the overhead of writing the journal records 2- No gain for the pain. You can NEVER use the journal to reproduce the file because it's state would always be to the moment. If the disk crashes you'll have to restore from the IDS archives anyway. Art S. Kag...

RE: raw vs. cooked files under linux #3
We're about to setup a new client on IDS 10 on Linux and I've now seen two recommendations for SUSE in relation to IDS 10. Does anyone have experience with Redhat Enterprise Edition and IDS 10? Any issues there that we should be aware of? Bill Weaver Director of Engineering Amicus, Inc. 512-531-3463 (office) 512-531-3401 (fax) -----Original Message----- From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] On Behalf Of Sandor Szabo Sent: Wednesday, May 11, 2005 6:31 AM To: Heinz Weitkamp Cc: user-group Informix (E-Mail); owner-informix-list@iiug.org Subject: Re: raw vs. cooked files under linux Dear Heinz, I would suggest that you pick SUSE SLES 9 This SUSE version works perfectly with IDS 10. Please check the following link: http://www-306.ibm.com/software/data/informix/linux/ids.html With IDS 10 you have the freedom of choice to use cooked or raw devices with KAIO This link should answer your raw device support question http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0503szabo/? ca=dgr-lnxw41IDSTen Let me know if you have any additional questions. bye Sandor IBM Informix Development Munich Information Management Hollerithstra�e 1 81829 Munich Germany Phone: +49 89 4504 1429 "Heinz Weitkamp" <heinz.wei...

RE: raw vs. cooked files under linux #9
-----Original Message----- From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] On Behalf Of John Carlson Sent: 13 May 2005 03:48 AM > >Almost zero? Will you be in Denver? Come see how many Informix DBAs attend >my own sessions or Jonathan's or Lester's. There are a lot more of us out >there then you imagine. > [snip] >As for the job security comments . . . just remember that there are >still a goodnumber of DBAs who will not be able to go to Denver. True, my company will only allow me to go places I can drive to (short distance) - very sad ........ sending to informix-list ...

Re: raw vs. cooked files under linux #10
DA Morgan said: > Data Goob wrote: >> Art, >> >> Your points are well made, and I'm willing to admit I could be >> misinformed, but quite honestly you are working in an exceptional >> environment compared to a lot of environments out there. You >> make the assertion that everyone should simply get it when it >> comes to disk drives, and quite honestly very few of us can keep >> up with this. You also make the assumption that it is easy when >> you should see what I have to work with when using sys admins--you >> even allude to the jr DBA who got it wrong. Imagine that this is >> 95% of the environments out there. And as far as misinforming >> people bang on EMC, they even preach their RAID5 is 'better', >> so we even have to deal with that as well as a lot of other >> vendor misinformation. > > There actually is one implementation of RAID5 that stands up to testing > as far superior to others and that is Apple Computer's XServe RAID. > These units have two XOR engines and come remarkably close in > performance to 0+1 (within a few percentage points) and also have the > advantage of having minimal loss of performance when running in degraded > mode. So far this year most of the storage I have worked with has been > Apple's and it is a poorly kept secret that Oracle Corp. is now using > them in their data center in...

RE: raw vs. cooked files under linux #5
We use raw chunks on all our unix versions. Most are Linux. We find it easier to set up and manage raw devices, including under Linux. We also have a SAN environment running RAW devices under Linux - no problems at all. We have not had any issues and that includes recovering systems. Its all very simple when using RAW devices. MW > -----Original Message----- > From: owner-informix-list@iiug.org > [mailto:owner-informix-list@iiug.org] On Behalf Of Data Goob > Sent: Thursday, 12 May 2005 1:09 p.m. > To: informix-list@iiug.org > Subject: Re: raw vs. cooked files under linux > > Art S. Kagel wrote: > > Heinz Weitkamp wrote: > > > >> Hi all, > > > > > > Go RAW all the way. Contrary to the Goob's understanding my own > > testing shows RAW devices to be 15-25% faster than COOKED devices > > which are in turn 10-15% faster than filesystem files, even on the > > best filesystem implementations that adds up to a 25% improvement. > > Well worth any minor inconveniences in my book. > > OK so you get some speed increases, but also the additional management > of linking raw files. The original post indicated he was a newbie. > Raw files are not necessarily difficult, but they ARE optional and not > something I would entrust to a newbie. It's a great learning > experience, but who's paying for it?? > > But anot...

Re: raw vs. cooked files under linux #4
I guess almost all of us are convinced at this point of the performance improvement from using raw devices. But it would be great if we could get a benchmark report with a couple of Filesystems, specially on Linux, just in case we really need to use Filesystems. (JFS, Ext3, XFS , ReiserFS, ... ) I am a fan of XFS on Linux, because of its speed/stability/reliability against the other filesystems. I would be glad to see if XFS is better for database-OLTP performance or not. Could someone point us to a benchmark report of filesystems/raw devices ? Best Regards ----- Original Message ----- From: "Art S. Kagel" <kagel@bloomberg.net> To: <informix-list@iiug.org> Sent: Wednesday, May 11, 2005 1:30 PM Subject: Re: raw vs. cooked files under linux > Heinz Weitkamp wrote: > > Hi all, > > Go RAW all the way. Contrary to the Goob's understanding my own testing > shows RAW devices to be 15-25% faster than COOKED devices which are in turn > 10-15% faster than filesystem files, even on the best filesystem > implementations that adds up to a 25% improvement. Well worth any minor > inconveniences in my book. I have not yet tested Linux RAW devices versus > the various filesystems that Linux directly supports, but early reports when > Linux RAW devices were first rolled out showed similar results. The > performance gain was one reason why Linus Torvalds was convinced finally to > ...

Re: raw vs. cooked files under linux #7
We are running 24 instances of IDS 9.4 on 24 machines - about 95% raw chunks - no problems so far -Can you explain some of your reasoning below? What specifically are the risks and additional management? ----- Original Message ----- From: "Data Goob" <datagoob@netscape.net> To: <informix-list@iiug.org> Sent: Wednesday, May 11, 2005 9:08 PM Subject: Re: raw vs. cooked files under linux > Art S. Kagel wrote: > > Heinz Weitkamp wrote: > > > >> Hi all, > > > > > > Go RAW all the way. Contrary to the Goob's understanding my own testing > > shows RAW devices to be 15-25% faster than COOKED devices which are in > > turn 10-15% faster than filesystem files, even on the best filesystem > > implementations that adds up to a 25% improvement. Well worth any minor > > inconveniences in my book. > > OK so you get some speed increases, but also the additional management > of linking raw files. The original post indicated he was a newbie. > Raw files are not necessarily difficult, but they ARE optional and not > something I would entrust to a newbie. It's a great learning experience, > but who's paying for it?? > > But another point to make is that in many SAN environments, raw files are > a complete waste of time, with the data already being spread out over many > drives, and, with speeds typically in the 10-15K rpm ran...

RE: raw vs. cooked files under linux #6
When you compare cooked versus raw here, are you focusing on Linux only, or talking about this in general - other Unix platforms as well ? -----Original Message----- From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] On Behalf Of Data Goob Sent: 11 May 2005 03:08 PM To: informix-list@iiug.org Subject: Re: raw vs. cooked files under linux If you are in a slow-change environment raw-files are not a bad thing. They create extra problems on the management side that cooked files do not. Fast-changing environments create more demand on your time so why put yourself into extra work with raw files? They don't give you enough of a difference in performance to really warrant them unless you are really demanding that extra 10%. Cooked files are also also more flexible on backups, you can back the dbspaces up with a regular backup tool or use the Informix backup tools, but raw files will have to be backed up with Informix tools only. SLES9 is quite a sea change from SLES8, and you could probably get away without SLES and go with the workstation Pro 9.3 if you are on a budget. SLES has better support for SCSI than the workstation versions and you must buy support or the online update doesn't work. It's an enterprise lock-in you might not need so try before you buy. SLES9 can be downloaded for trial, so give it a spin. You should be able to download IDS 10 for trial as well, thus no out of pocket to try it before pay...

Re: Relocate Informix database from Raw slices to filesystem #2
Why pay someone ??? It's a trivial task On 10/17/05, Neil Truby <neil.truby@ardenta.com> wrote: > > <mccmx@hotmail.com> wrote in message > news:1129561344.240798.314750@g49g2000cwa.googlegroups.com... > > Thats sounds promising. > > > > So effectively add a mirrored chunk to each dbspace using onspaces and > > then drop the original chunk. > > > > Can you do this for the rootdbs dbspace too...? > > > > Matt > > > > If it's a production system you might be better off paying someone who > knows > what they're doing to do this for you. > > -- > Neil Truby t:01932 724027 > Director m:07798 811708 > Ardenta Limited e:neil.truby@ardenta.com > > > > -- Paul Watson Tel: +44 7818 003457 Fax: +44 1436 678693 sending to informix-list ...

RE: Raw device VS cooked file
In my experience with AIX. The new enhanced journal file system (JFS2), there are file system option to use SIO or DIO. Using DIO (direct io) gives pretty close results to raw partition with Oracle and Informix. I am not sure if Solaris, HPUX or Linux has any option similar to AIX Basim Chafik Senior Systems Analyst IBM Certified Advanced Technical Expert (CATE) 1.800.688.4895 basim.chafik@plx.com plexus (Division of BancTec) -----Original Message----- From: Rupan3rd [mailto:rupan.nospam.3rd@hotmail.com] Sent: Thursday, January 12, 2006 11:18 AM To: informix-list@iiug.org Subject: Re: Raw device VS cooked file - any benchmark recently done? I know what pros and cons of using raw might be. My need is to have the best performance for my OLTP system, therefore I was wordering if and in what cases it might be actually true that there are disk devices able to achieve "I/O caching for cooked writes" that "can provide similar if not better performance" than raw areas. Still the documentation does not explicitly say if the cooked READS would be that good as well nor how to benchmark nor the effect of the fragmentation. Regards Rupan3rd malcolm weallans wrote: > I would really like to see any evidence that people have on this issue. I > have a number of systems that are running with acceptable performance on raw > disks. But could we be doing better and at what cost? > > But from almost ...

Re: Database Lock vs Database Freeze #2
Well Madan, Gerhard already gave you two possible meanings of both terms, which I think may be associated with either term. I would like to add a third meaning that could be expressed by either term as well. In this meaning it would imply that the database building process has been declared finished, stopped, whether or not new data are still coming in. The data that are already in the database have been _cleaned_ and _unblinded_. The database is frozen, locked. It may have been made physically impossible to add or change anything or it only has the status of a final db. This state of the db ...

Re: FINFO
Got it. Thanks. ----- Original Message ----- From: "Stan Sieler" <sieler@allegro.com> To: <HP3000-L@RAVEN.UTC.EDU> Sent: Friday, November 21, 2003 18:10 Subject: Re: [HP3000-L] FINFO - temp files vs perm files > > Is there a way to force FINFO to report on only temp files? Or, on only permanent files? > > <snip> > > > This seems to work: > > :file xx, oldtemp > :calc finfo ("*xx", "exists") > > Note the "*" in the filename given to FINFO. If no temp "xx" exi...

Re: AIFFILEGGET -- Perm file vs Temp File Problem #2
The saga continues. Well, not really, got an answer from the AIF techie a= t=20 HP just a few days ago. The results returned by AIFFILEGGET differs between perm and temp files. There are three ways to access a file's attributes with this intrinsic. Scenario #1 --=20 Perm file 1) Go in by the File Name returns a -43 if file not found 2) Go in by the UFID returns -42 if file not found 3) Go in by HFS pathname returns a -66 if file not found. Tempfile parm is boolean zeroes. Correct for perm files. Scenario #2 -- Temp file=20 1) Go in by the File Name retur...

RE: [Maybe spam] Re: Relation of OS user to Informix database #2
You can only revoke a privilege that exists explicitly and you are the GRANTOR, if a user's rights are part of "public" then you cannot prevent the access unless you revoke connection privileges from public Regards Colin There are 10 types of people in the world, those that understand binary and those that don't >From: "Gosney Simon" <GosneyS@axxia.com> >To: "Jonathan Leffler" <jleffler@earthlink.net>, <informix-list@iiug.org> >Subject: RE: [Maybe spam] Re: Relation of OS user to Informix database >user >Date: Thu, 25 Aug 2005 08:48:31 +0100 > >Jonathan... am I correct in thinking that you can't revoke rights from a >user who has those rights because they're a member of public? > >Ie, if they don't have the rights assigned with an explicit GRANT >statement, then you can't revoke their rights without revoking public's >rights and then granting permissions to all other users individually? > >Cheers > >Simon > >-----Original Message----- >From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] >On Behalf Of Jonathan Leffler >Sent: 25 August 2005 05:24 >To: informix-list@iiug.org >Subject: [Maybe spam] Re: Relation of OS user to Informix database user > >anupam.mukherjee@gmail.com wrote: > > I had just installed Informix Advanced Server version 10.0 f...

Re: 2xSMP vs RAC for failover
DA Morgan said: > > Serge Rielau wrote: > >> Duly noted. Thoughts for the road: If you use a 2 node cluster and one >> goes down you're dead unless you kept load very low when the RAC system >> is up. That is the 2 node RAC cluster competes with a 2x4 SMP box which >> of course will price hardware wise the same (minus the 2 switches + >> disk). You did not price out the equivalent dataguard solution, btw. >> >> Cheers and bye >> Serge > > And Obnoxio's objection duly noted here so one closing thought and I too > end the thread. > > That quick comment being that you just build in one extra node so if > one burns itself to the ground ... you still have what you need. And > given the low cost of an extra node (a few thousands dollars): Who cares. Yes, Daniel. We all expect you to get the last word in. Tosser. -- Bye now, Obnoxio "C'est pas parce qu'on n'a rien ` dire qu'il faut fermer sa gueule" - Coluche did i mention i like nulls? heck, i even go so far as to say that all columns in a table except the primary key could/should be nullable. this has certain advantages, for example, if you need to insert a child record and you don't have a parent row for it, just do an insert into the parent table with the primary key value (everything else null), and voila, relational integrity is preserved. but this is, admittedly, a ...

Re: Re: I want to open a doc file in window dir using informix #2
If you download the V4.2 you will see an example of what you want in the demo program. https://www.querix.com/cgi-bin/refreshprog?login On 21 Sep 2005 at 12:57, Jean Sagi wrote: > Thanks, > > Very interesting indeed. > > I would be more intertested in option 1) you give. I need to have MS Word in orther to view the document, isn't it? > > > J > > -----Original Message----- > From: mehdi2@querix.com > To: Jean Sagi <jeansagi@myrealbox.com>, informix-list@iiug.org, calyanram@hotmail.com > Date: Wed, 21 Sep 2005 11:25:20 +0100 > Subject: Re: I want to open a doc file in window dir using informix 4gl > > Hi Jean, > > Lets look at the following scenarios, > > 1) You have a BLOB / CLOB file (which may be anything including a > .doc file) in the database. > > You can display and edit it as you will with any other data when you are > using Querix, so if the file is sent to an Input field for update this is > exactly what you can do with it. > > 2) You have a document file stored some wher on a network, you are > only keeping the information about the place wher it is stored and you > only display the link in field. > > Here again you can open the file and if the file is not a read only you > can edit it. All you need is to clik on the link. > > 3) You have some information on the database you want to send to a ...

Raw vs. Cooked files
Hello, I am installing IDS 10 on RHEL3 on an intel x86 server. I need to make the choice between raw devices and cooked files. I found the following information in the FAQ's. Is this information still accurate? Do cooked files continue to be significantly slower than the raw files? I have heard that UNIX file systems have improved over the years and the performance divide between raw and cooked files has narrowed considerabley. Is it true? Thanks! - Rajesh -------------------------------------------------------------------------------------- 6.38 Is raw disk faster than cooked files? On 22nd Jun 1998 kagel@bloomberg.net (Art S. Kagel) wrote:- .....................the safety issue of cooked files is no longer a problem. The big problem with cooked files still is performance. All writes and reads to/from cooked files MUST go through the UNIX buffer cache. This means an additional copy from the server's output buffer to the UNIX buffer page then a synchronous write to disk. This is opposed to a write to a way file where the server's output buffer is written directly to disk without the intervening copy. This is just faster. Anyone who has written anything that can test this can attest to the difference in speed. Here are my test results: FileType Sync? Times (real/user/system) 2run avg --------------- ----- ----------------------------------------- Filesystem file N 14.40/3.70/2.52 Y 15.02/3.61/2.63 Cooked ...

Re: hi Cant load informix online 5.2 on linux -8 ( rpm file) #2
Hi, As Tsutomu said it's a bug in the RPM package of Red Hat 8, I know two workarounds: 1. - When you get the error message type 'OVERRIDE', (all caps and without the apostrophe). 2 . export RPM_INSTALL_PREFIX=/opt/informix export INFORMIXDIR=/opt/informix install without any relocation HTH ----- Original Message ----- From: "RATHER" <myzahoor@yahoo.co.uk> To: <informix-list@iiug.org> Sent: Friday, December 26, 2003 11:57 PM Subject: hi Cant load informix online 5.2 on linux -8 ( rpm file) > Hello friends > > RE...

Web resources about - Re: Raw vs. Cooked files #2 - comp.databases.informix

Punky Brüster – Cooked on Phonics - Wikipedia, the free encyclopedia
Punky Brüster – Cooked on Phonics (a pun of the literacy program Hooked on Phonics ) is the debut studio album by Canadian musician Devin Townsend ...

The cooked veggieducken - Flickr - Photo Sharing!
Explore The Sporkful's photos on Flickr. The Sporkful has uploaded 46 photos to Flickr.

Chef dismembered, cooked girlfriend in Brisbane apartment
A young chef had been boiling his girlfriend's dismembered body parts in his Brisbane apartment when he was discovered by police on Saturday ...


Carbon tax not all it was cooked up to be
Carbon tax not all it was cooked up to be

HomeCooked app: Buy your neighbour’s home-cooked food instead of takeaways - The Courier-Mail Search ...
WE COULD soon be bidding farewell to the fish and chip shop and saying ta-ta to the takeaway Thai if a plan to transform the way we eat, in the ...


Tanzanian man 'beheaded and cooked'
A Tanzanian man has been beheaded and cooked following accusations of adultery.

They came, they cooked, they conquered: it's all about being Italian
They came, they cooked, they conquered: it's all about being Italian

The books are being cooked on 457 visas
The foreign worker program is being rorted just as the student visas were.

Resources last updated: 3/1/2016 4:50:10 AM