Raw Partition Vs Cooked FileSystem
A user running IDS 11.1 on RHEL 5.1 with a small (~500MB) database asked whether to use raw partitions or cooked filesystem chunks. Consensus: raw is fastest (rule of thumb ~15% over cooked devices, ~25% over filesystem files), but with IDS 11.1 and RHEL 5.1 you can set DIRECT_IO=1 and cut the cooked-filesystem penalty to roughly 5%, which many find acceptable. Side discussion noted Linux raw bindings are being deprecated and that pointing a chunk at a block device is still cooked I/O. Art Kagel also advised separate temp dbspaces and separating logical/physical logs onto other spindles. No single choice was mandated — it's a trade-off between a few percent performance and administrative convenience/safety.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi All, I have an IDS 11.1 running on a quad core processor with RHEL 5.1 and a hard disk capacity of 80 GB. My database details: Root dbspace - 2.5 GB Dbspace 1 - 2.5 GB [ this contains the database] Maximum database size can go up to 537 MB only. My application requires periodic backup. I have been trying to figure out which would be suit my application - Raw partition or Cooked File system. Kindly help me out in evaluating the same for my application in terms of performance and access and response times. thanks and regards, g k
RAW if you can... cooked is a lot faster than it used to be but Raw is even faster. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of G K Sent: 11 September 2008 15:29 To: ids@iiug.org Subject: Raw Partition Vs Cooked FileSystem [13346] Hi All, I have an IDS 11.1 running on a quad core processor with RHEL 5.1 and a hard disk capacity of 80 GB. My database details: Root dbspace - 2.5 GB Dbspace 1 - 2.5 GB [ this contains the database] Maximum database size can go up to 537 MB only. My application requires periodic backup. I have been trying to figure out which would be suit my application - Raw partition or Cooked File system. Kindly help me out in evaluating the same for my application in terms of performance and access and response times. thanks and regards, g k ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.
On Linux? As far as I know, cooked with DIRECT_IO Raw devices aren't deprecated on Linux? On Thu, Sep 11, 2008 at 3:29 PM, G K <ganeshkumarr@hcl.in> wrote: > Hi All, > > I have an IDS 11.1 running on a quad core processor with RHEL 5.1 and a > hard > disk capacity of 80 GB. > > My database details: > > Root dbspace - 2.5 GB > Dbspace 1 - 2.5 GB [ this contains the database] > Maximum database size can go up to 537 MB only. > My application requires periodic backup. > > I have been trying to figure out which would be suit my application - Raw > partition or Cooked File system. > > Kindly help me out in evaluating the same for my application in terms of > performance and access and response times. > > thanks and regards, > g k > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...
The old rule of thumb was that RAW devices are ~15% faster than COOKED devices which are in turn ~10% faster than filesystem files (also COOKED). That makes RAW ~25% faster than COOKED filesystem files. You do have IDS 11.1 so your IDS version supports Direct IO as does (IB) RHEL 5.1, so if you enable Direct IO (DIRECT_IO set to 1 in the ONCONFIG file) you reduce the overhead of COOKED filesystem chunks from 25% to about 5% which is something you can live with if the convenience of having your chunks in filesystem space is a priority for you. Personally I think that chunks in filesystem space are more exposed to fumble fingering and naive system administrators, so I still prefer RAW. FYI, you should also configure at least one and preferably three smallish temp dbspaces for sorting and unlogged temp tables, especially if you can put them onto a separate structure. Ditto for the logical and physical logs. Remember that almost 50% of you write IO will be to the logical logs and over 50% if you include the physical log IO, so moving that bandwidth off to a separate set of spindles can be a big win if there is a significant write component to your systems. Art On Thu, Sep 11, 2008 at 10:29 AM, G K <ganeshkumarr@hcl.in> wrote: > Hi All, > > I have an IDS 11.1 running on a quad core processor with RHEL 5.1 and a > hard > disk capacity of 80 GB. > > My database details: > > Root dbspace - 2.5 GB > Dbspace 1 - 2.5 GB [ this contains the database] > Maximum database size can go up to 537 MB only. > My application requires periodic backup. > > I have been trying to figure out which would be suit my application - Raw > partition or Cooked File system. > > Kindly help me out in evaluating the same for my application in terms of > performance and access and response times. > > thanks and regards, > g k > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.
Not yet. Linus is still pressing to get rid of RAW, but it lives on. Art On Thu, Sep 11, 2008 at 10:35 AM, Fernando Nunes <domusonline@gmail.com>wrote: > On Linux? As far as I know, cooked with DIRECT_IO > Raw devices aren't deprecated on Linux? > > On Thu, Sep 11, 2008 at 3:29 PM, G K <ganeshkumarr@hcl.in> wrote: > > > Hi All, > > > > I have an IDS 11.1 running on a quad core processor with RHEL 5.1 and a > > hard > > disk capacity of 80 GB. > > > > My database details: > > > > Root dbspace - 2.5 GB > > Dbspace 1 - 2.5 GB [ this contains the database] > > Maximum database size can go up to 537 MB only. > > My application requires periodic backup. > > > > I have been trying to figure out which would be suit my application - Raw > > partition or Cooked File system. > > > > Kindly help me out in evaluating the same for my application in terms of > > performance and access and response times. > > > > thanks and regards, > > g k > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > -- > -- > Fernando Nunes > Portugal > > http://informix-technology.blogspot.com > My email works... but I don't check it frequently... > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.
One ponit of clarification for Linux. I thought that what was to be deprecated was the method of binding a raw character device to a block device using the 'raw'. But using IDS (recent version) on Linux (recent version) you can also skip that and simply point your chunk to the block device. Jim On Thu, Sep 11, 2008 at 11:40 AM, Art Kagel <art.kagel@gmail.com> wrote: > Not yet. Linus is still pressing to get rid of RAW, but it lives on. > > Art > > On Thu, Sep 11, 2008 at 10:35 AM, Fernando Nunes <domusonline@gmail.com>wrote: > >> On Linux? As far as I know, cooked with DIRECT_IO >> Raw devices aren't deprecated on Linux? >> >> On Thu, Sep 11, 2008 at 3:29 PM, G K <ganeshkumarr@hcl.in> wrote: >> >> > Hi All, >> > >> > I have an IDS 11.1 running on a quad core processor with RHEL 5.1 and a >> > hard >> > disk capacity of 80 GB. >> > >> > My database details: >> > >> > Root dbspace - 2.5 GB >> > Dbspace 1 - 2.5 GB [ this contains the database] >> > Maximum database size can go up to 537 MB only. >> > My application requires periodic backup. >> > >> > I have been trying to figure out which would be suit my application - Raw >> > partition or Cooked File system. >> > >> > Kindly help me out in evaluating the same for my application in terms of >> > performance and access and response times. >> > >> > thanks and regards, >> > g k >> > >> > >> > >> > >> >> > ******************************************************************************* >> > Forum Note: Use "Reply" to post a response in the discussion forum. >> > >> > >> >> -- >> -- >> Fernando Nunes >> Portugal >> >> http://informix-technology.blogspot.com >> My email works... but I don't check it frequently... >> >> >> >> > ******************************************************************************* >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> > > -- > Art S. Kagel > Oninit (www.oninit.com) > IIUG Board of Directors (art@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions and > do not reflect on my employer, Oninit, the IIUG, nor any other organization > with which I am associated either explicitly or implicitly. Neither do those > opinions reflect those of other individuals affiliated with any entity with > which I am affiliated nor those of the entities themselves. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >
Does it work ok? Using block devices I mean? I have the idea that this causes performance issues.... It's not an idea based on solid technical facts... Regards, On Thu, Sep 11, 2008 at 7:24 PM, Jim Tranny <jimtranny@gmail.com> wrote: > One ponit of clarification for Linux. I thought that what was to be > deprecated was the method of binding a raw character device to a block > device using the 'raw'. > > But using IDS (recent version) on Linux (recent version) you can also > skip that and simply point your chunk to the block device. > > Jim > > On Thu, Sep 11, 2008 at 11:40 AM, Art Kagel <art.kagel@gmail.com> wrote: > > Not yet. Linus is still pressing to get rid of RAW, but it lives on. > > > > Art > > > > On Thu, Sep 11, 2008 at 10:35 AM, Fernando Nunes > <domusonline@gmail.com>wrote: > > > >> On Linux? As far as I know, cooked with DIRECT_IO > >> Raw devices aren't deprecated on Linux? > >> > >> On Thu, Sep 11, 2008 at 3:29 PM, G K <ganeshkumarr@hcl.in> wrote: > >> > >> > Hi All, > >> > > >> > I have an IDS 11.1 running on a quad core processor with RHEL 5.1 and > a > >> > hard > >> > disk capacity of 80 GB. > >> > > >> > My database details: > >> > > >> > Root dbspace - 2.5 GB > >> > Dbspace 1 - 2.5 GB [ this contains the database] > >> > Maximum database size can go up to 537 MB only. > >> > My application requires periodic backup. > >> > > >> > I have been trying to figure out which would be suit my application - > Raw > >> > partition or Cooked File system. > >> > > >> > Kindly help me out in evaluating the same for my application in terms > of > >> > performance and access and response times. > >> > > >> > thanks and regards, > >> > g k > >> > > >> > > >> > > >> > > >> > >> > > > > ******************************************************************************* > >> > Forum Note: Use "Reply" to post a response in the discussion forum. > >> > > >> > > >> > >> -- > >> -- > >> Fernando Nunes > >> Portugal > >> > >> http://informix-technology.blogspot.com > >> My email works... but I don't check it frequently... > >> > >> > >> > >> > > > > ******************************************************************************* > >> Forum Note: Use "Reply" to post a response in the discussion forum. > >> > >> > > > > -- > > Art S. Kagel > > Oninit (www.oninit.com) > > IIUG Board of Directors (art@iiug.org) > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and > > do not reflect on my employer, Oninit, the IIUG, nor any other > organization > > with which I am associated either explicitly or implicitly. Neither do > those > > opinions reflect those of other individuals affiliated with any entity > with > > which I am affiliated nor those of the entities themselves. > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...
But the block device is COOKED not RAW, it still funnels data through the system buffer cache unless you use O_DIRECT mode IO. The Administrator's Reference manual says: DIRECT_IO is not used for temporary dbspaces and can only be used for dbspace chunks whose file systems support direct I/O for the page size. I have not tested whether direct io is actually used if you point a chunk to a block device. Without direct IO block devices suffer a performance penalty of about 10% which is nearly double the typical performance of a filesystem file with direct IO enabled. For maximum throughput, you still want to do the RAW binding if it's available. The only remaining question is whether the possible 5% incremental performance gain is worth the hassle of creating the RAW device links/bindings and that's up to the SA's and DBA's on the scene. If you are not pushing your system's IO capacity anyway, will you notice the difference? Maybe maybe not. Art On Thu, Sep 11, 2008 at 2:24 PM, Jim Tranny <jimtranny@gmail.com> wrote: > One ponit of clarification for Linux. I thought that what was to be > deprecated was the method of binding a raw character device to a block > device using the 'raw'. > > But using IDS (recent version) on Linux (recent version) you can also > skip that and simply point your chunk to the block device. > > Jim > > On Thu, Sep 11, 2008 at 11:40 AM, Art Kagel <art.kagel@gmail.com> wrote: > > Not yet. Linus is still pressing to get rid of RAW, but it lives on. > > > > Art > > > > On Thu, Sep 11, 2008 at 10:35 AM, Fernando Nunes > <domusonline@gmail.com>wrote: > > > >> On Linux? As far as I know, cooked with DIRECT_IO > >> Raw devices aren't deprecated on Linux? > >> > >> On Thu, Sep 11, 2008 at 3:29 PM, G K <ganeshkumarr@hcl.in> wrote: > >> > >> > Hi All, > >> > > >> > I have an IDS 11.1 running on a quad core processor with RHEL 5.1 and > a > >> > hard > >> > disk capacity of 80 GB. > >> > > >> > My database details: > >> > > >> > Root dbspace - 2.5 GB > >> > Dbspace 1 - 2.5 GB [ this contains the database] > >> > Maximum database size can go up to 537 MB only. > >> > My application requires periodic backup. > >> > > >> > I have been trying to figure out which would be suit my application - > Raw > >> > partition or Cooked File system. > >> > > >> > Kindly help me out in evaluating the same for my application in terms > of > >> > performance and access and response times. > >> > > >> > thanks and regards, > >> > g k > >> > > >> > > >> > > >> > > >> > >> > > > > ******************************************************************************* > >> > Forum Note: Use "Reply" to post a response in the discussion forum. > >> > > >> > > >> > >> -- > >> -- > >> Fernando Nunes > >> Portugal > >> > >> http://informix-technology.blogspot.com > >> My email works... but I don't check it frequently... > >> > >> > >> > >> > > > > ******************************************************************************* > >> Forum Note: Use "Reply" to post a response in the discussion forum. > >> > >> > > > > -- > > Art S. Kagel > > Oninit (www.oninit.com) > > IIUG Board of Directors (art@iiug.org) > > > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and > > do not reflect on my employer, Oninit, the IIUG, nor any other > organization > > with which I am associated either explicitly or implicitly. Neither do > those > > opinions reflect those of other individuals affiliated with any entity > with > > which I am affiliated nor those of the entities themselves. > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.