raw device on suse10.1
Posted in 2006
A user benchmarked IDS 10 dbimport times on SUSE 10.1 (2.6 kernel) across raw partition, ext2, ext3, xfs and reiser (raw and ext2 fastest), and asked whether he could skip the raw-bind step and just point Informix at an unmounted block device like /dev/sda12. Replies: raw binding does still work (edit /etc/raw, start the raw service, and install libaio), but on 2.6 kernels the rawio interface is deprecated in favour of opening block devices with O_DIRECT, and IDS 10 supports KAIO on both character and block devices — so using the block device directly (or LVM volumes) is fine and preferred over a filesystem. It was also noted a single dbimport is a weak performance test; no firm filesystem recommendation emerged.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Performance & Tuning, Server Administration, Platform-Specific Issues
Hi, i did some simple tests because of the performance of different file systems and raw device under suse linux 10.1 (uname -a: 2.6.13-4-smp) and ids10.00.UC4. I was not able to bind a block-device to a raw device with the raw-command. Is that right ??? So I handled the unmounted partition(no fs) /dev/sda12 as raw-device. All instances are identical (same onconfig except identification parameters). The instances were made from same archive with rename-option. I testet import-time of a database (real time of time-command): raw 23m11.4 ext2 23m16.8 ext3 30m0.4 xfs 32m37.8 reiser 53m6.1 the file systems and the raw partition are on the same SATA-disk (aprox. 300GB). my questions: the raw partition and ext2 are fastest, is it right, to handle /dev/sda12 like a raw partition (benefits,advantages)? I had no control over the position of the tracks. Is there a noticeable influence of track-position on performance? TIA ruediger papke
> i did some simple tests because of the performance of different file
> systems and raw device under suse linux 10.1 (uname -a: 2.6.13-4-smp)
> and ids10.00.UC4.
> I was not able to bind a block-device to a raw device with the
> raw-command.
> Is that right ???
Nope, it works just fine. Edit /etc/raw and start the raw service.
> So I handled the unmounted partition(no fs) /dev/sda12 as raw-device.
> All instances are identical (same onconfig except identification
> parameters). The instances were made from same archive with
> rename-option.
> I testet import-time of a database (real time of time-command):
> raw 23m11.4
> ext2 23m16.8
> ext3 30m0.4
> xfs 32m37.8
> reiser 53m6.1
> the file systems and the raw partition are on the same SATA-disk
> (aprox. 300GB).
> my questions:
> the raw partition and ext2 are fastest, is it right, to handle
> /dev/sda12 like a raw partition (benefits,advantages)?
But better it you bind it to a raw device, and make sure libaio is
installed. Informix seems to run without libaio, but it posts a
complaint in the logs.
I also don't think a dbimport is a very effective performance test; it
tells you something but I'm not certain what. I think multiple
readers/writers would be much more informative test.
> I had no control over the position of the tracks. Is there a noticeable
> influence of track-position on performance?
tracks?
ruediger.papke@t-online.de wrote: > Hi, > > i did some simple tests because of the performance of different file > systems and raw device under suse linux 10.1 (uname -a: 2.6.13-4-smp) > and ids10.00.UC4. > > I was not able to bind a block-device to a raw device with the > raw-command. > Is that right ??? > > So I handled the unmounted partition(no fs) /dev/sda12 as raw-device. > > All instances are identical (same onconfig except identification > parameters). The instances were made from same archive with > rename-option. > > I testet import-time of a database (real time of time-command): > raw 23m11.4 > ext2 23m16.8 > ext3 30m0.4 > xfs 32m37.8 > reiser 53m6.1 > > the file systems and the raw partition are on the same SATA-disk > (aprox. 300GB). > my questions: > the raw partition and ext2 are fastest, is it right, to handle > /dev/sda12 like a raw partition (benefits,advantages)? > I had no control over the position of the tracks. Is there a noticeable > influence of track-position on performance? > > TIA > ruediger papke > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > > > On Linux kernel 2.6.x raw dvices are obsolete. This is from a RHEL 4 release notes: "Although Red Hat Enterprise Linux 4 includes support for rawio, it is now a deprecated interface. If your application performs device access using this interface, Red Hat encourages you to modify your application to open the block device with the *O_DIRECT* flag. The rawio interface will exist for the life of Red Hat Enterprise Linux 4, but is a candidate for removal from future releases. Asynchronous I/O (AIO) on file systems is currently only supported in *O_DIRECT*, or non-buffered mode. Also note that the asynchronous poll interface is no longer present, and that AIO on pipes is no longer supported." And this is from IDS 10: " Kernel Asynchronous I/O (KAIO) Asynchronous I/O is supported by the official Linux kernel since version 2.6.x. IBM Informix Dynamic Server supports Kernel Asynchronous I/O (KAIO) on character devices (a.k.a. raw devices) and */_block devices._/* It is enabled by default, and can be disabled by setting the environment variable KAIOOFF=1 in the environment of the process that brings up the server." Dimitar Bachvarov
Dimitar Bachvarov wrote: > ruediger.papke@t-online.de wrote: > > Hi, > > > > i did some simple tests because of the performance of different file > > systems and raw device under suse linux 10.1 (uname -a: 2.6.13-4-smp) > > and ids10.00.UC4. > > > > I was not able to bind a block-device to a raw device with the > > raw-command. > > Is that right ??? > > > > So I handled the unmounted partition(no fs) /dev/sda12 as raw-device. > > > > All instances are identical (same onconfig except identification > > parameters). The instances were made from same archive with > > rename-option. > > > > I testet import-time of a database (real time of time-command): > > raw 23m11.4 > > ext2 23m16.8 > > ext3 30m0.4 > > xfs 32m37.8 > > reiser 53m6.1 > > > > the file systems and the raw partition are on the same SATA-disk > > (aprox. 300GB). > > my questions: > > the raw partition and ext2 are fastest, is it right, to handle > > /dev/sda12 like a raw partition (benefits,advantages)? > > I had no control over the position of the tracks. Is there a noticeable > > influence of track-position on performance? > > > > TIA > > ruediger papke > > > > _______________________________________________ > > Informix-list mailing list > > Informix-list@iiug.org > > http://www.iiug.org/mailman/listinfo/informix-list > > > > > > > On Linux kernel 2.6.x raw dvices are obsolete. > This is from a RHEL 4 release notes: > "Although Red Hat Enterprise Linux 4 includes support for rawio, it is > now a deprecated interface. If your application performs device access > using this interface, Red Hat encourages you to modify your application > to open the block device with the *O_DIRECT* flag. The rawio interface > will exist for the life of Red Hat Enterprise Linux 4, but is a > candidate for removal from future releases. > > Asynchronous I/O (AIO) on file systems is currently only supported in > *O_DIRECT*, or non-buffered mode. Also note that the asynchronous poll > interface is no longer present, and that AIO on pipes is no longer > supported." > > And this is from IDS 10: > " > > Kernel Asynchronous I/O (KAIO) > > Asynchronous I/O is supported by the official Linux kernel since version > 2.6.x. IBM Informix Dynamic Server supports Kernel Asynchronous I/O (KAIO) > on character devices (a.k.a. raw devices) and */_block devices._/* It is enabled > by default, and can be disabled by setting the environment variable > KAIOOFF=1 in the environment of the process that brings up the server." > > > > > Dimitar Bachvarov > > > --------------000009060008040402080605 > Content-Type: text/html; charset=ISO-8859-1 > X-Google-AttachSize: 3049 > > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > <html> > <head> > <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> > </head> > <body bgcolor="#ffffff" text="#000000"> > <a class="moz-txt-link-abbreviated" href="mailto:ruediger.papke@t-online.de">ruediger.papke@t-online.de</a> wrote: > <blockquote > cite="mid1163327908.961797.96190@i42g2000cwa.googlegroups.com" > type="cite"> > <pre wrap="">Hi, > > i did some simple tests because of the performance of different file > systems and raw device under suse linux 10.1 (uname -a: 2.6.13-4-smp) > and ids10.00.UC4. > > I was not able to bind a block-device to a raw device with the > raw-command. > Is that right ??? > > So I handled the unmounted partition(no fs) /dev/sda12 as raw-device. > > All instances are identical (same onconfig except identification > parameters). The instances were made from same archive with > rename-option. > > I testet import-time of a database (real time of time-command): > raw 23m11.4 > ext2 23m16.8 > ext3 30m0.4 > xfs 32m37.8 > reiser 53m6.1 > > the file systems and the raw partition are on the same SATA-disk > (aprox. 300GB). > my questions: > the raw partition and ext2 are fastest, is it right, to handle > /dev/sda12 like a raw partition (benefits,advantages)? > I had no control over the position of the tracks. Is there a noticeable > influence of track-position on performance? > > TIA > ruediger papke > > _______________________________________________ > Informix-list mailing list > <a class="moz-txt-link-abbreviated" href="mailto:Informix-list@iiug.org">Informix-list@iiug.org</a> > <a class="moz-txt-link-freetext" href="http://www.iiug.org/mailman/listinfo/informix-list">http://www.iiug.org/mailman/listinfo/informix-list</a> > > > </pre> > </blockquote> > On Linux kernel 2.6.x raw dvices are obsolete.<br> > This is from a RHEL 4 release notes:<br> > "Although Red Hat Enterprise Linux 4 includes support for rawio, it is > now a deprecated interface. If your application performs device access > using this interface, Red Hat encourages you to modify your application > to open the block device with the <span><b class="command">O_DIRECT</b></span> > flag. The rawio interface will exist for the life of Red Hat Enterprise > Linux 4, but is a candidate for removal from future releases. > <p>Asynchronous I/O (AIO) on file systems is currently only supported > in <span><b class="command">O_DIRECT</b></span>, or non-buffered mode. > Also note that the asynchronous poll interface is no longer present, > and that AIO on pipes is no longer supported."<br> > </p> > <p>And this is from IDS 10:<br> > "<br> > </p> > <pre>Kernel Asynchronous I/O (KAIO) > > Asynchronous I/O is supported by the official Linux kernel since version > 2.6.x. IBM Informix Dynamic Server supports Kernel Asynchronous I/O (KAIO) > on character devices (a.k.a. raw devices) and <b><i><u>block devices.</u></i></b> It is enabled > by default, and can be disabled by setting the environment variable > KAIOOFF=1 in the environment of the process that brings up the server." > > > > </pre> > <p>Dimitar Bachvarov<br> > </p> > </body> > </html> > > --------------000009060008040402080605-- I was just about to start a thread regarding what to choose for IDS 9.40 or 10 on Linux. In SuSE releases with 2.4.21 kernels I used raw devices and was satisfied. But I did hear somewhere that raw access will be dessuported. Is it possible that raw devices will be supported in some distros (e.g. SuSE) and not in others, or the feature will be completely removed from further Linux development? Why? I seem to remember that Mr Torvald Linus was not proponent of raw devices, so that feature was included rather lately (in kernel 2.2?). Is it wise to start using file systems for IDS storage with 2.6 kernels now? (I prefer raw devices whenever possible. I don't agree that it makes administration harder or more complex. Quite the opposite, there is less chance that someone can mess something up if Informix database is not in filesystems.) Which filesystem type for IDS databases is recommended
> I was just about to start a thread regarding what to choose for IDS > 9.40 or 10 on Linux. In SuSE releases with 2.4.21 kernels I used raw > devices and was satisfied. But I did hear somewhere that raw access > will be dessuported. Use the "raw" device, but you can just use the block device; as I read it you don't need the special raw-device anymore. You get the same behaviour by opening the block device with O_DIRECT. > Is it possible that raw devices will be supported in some distros (e.g. > SuSE) and not in others, or the feature will be completely removed from > further Linux development? Why? Eventually it will be removed. It just adds unnecessary complexity. Why have two device interfaces when you can have one? > Linus was not proponent of raw devices, so that feature was included > rather lately (in kernel 2.2?). Is it wise to start using file systems > for IDS storage with 2.6 kernels now? I wouldn't. You can create logical volumes and use those as raw devices; you get the flexibility without the overhead of a filesystem. That and filesystems are just another layer where bugs can be introduced. > I have no experience with XFS, but from I've read about it, it seems to > be planned for different types of applications related to DBMSs. We use XFS allot; not for databases. I am concerned about future development however. > It > seems that IBM donated JFS is not in use much these days (if ever was). Yep.
darko wrote: > Dimitar Bachvarov wrote: > >> ruediger.papke@t-online.de wrote: >> >>> Hi, >>> >>> i did some simple tests because of the performance of different file >>> systems and raw device under suse linux 10.1 (uname -a: 2.6.13-4-smp) >>> and ids10.00.UC4. >>> >>> I was not able to bind a block-device to a raw device with the >>> raw-command. >>> Is that right ??? >>> >>> So I handled the unmounted partition(no fs) /dev/sda12 as raw-device. >>> >>> All instances are identical (same onconfig except identification >>> parameters). The instances were made from same archive with >>> rename-option. >>> >>> I testet import-time of a database (real time of time-command): >>> raw 23m11.4 >>> ext2 23m16.8 >>> ext3 30m0.4 >>> xfs 32m37.8 >>> reiser 53m6.1 >>> >>> the file systems and the raw partition are on the same SATA-disk >>> (aprox. 300GB). >>> my questions: >>> the raw partition and ext2 are fastest, is it right, to handle >>> /dev/sda12 like a raw partition (benefits,advantages)? >>> I had no control over the position of the tracks. Is there a noticeable >>> influence of track-position on performance? >>> >>> TIA >>> ruediger papke >>> >>> _______________________________________________ >>> Informix-list mailing list >>> Informix-list@iiug.org >>> http://www.iiug.org/mailman/listinfo/informix-list >>> >>> >>> >>> >> On Linux kernel 2.6.x raw dvices are obsolete. >> This is from a RHEL 4 release notes: >> "Although Red Hat Enterprise Linux 4 includes support for rawio, it is >> now a deprecated interface. If your application performs device access >> using this interface, Red Hat encourages you to modify your application >> to open the block device with the *O_DIRECT* flag. The rawio interface >> will exist for the life of Red Hat Enterprise Linux 4, but is a >> candidate for removal from future releases. >> >> Asynchronous I/O (AIO) on file systems is currently only supported in >> *O_DIRECT*, or non-buffered mode. Also note that the asynchronous poll >> interface is no longer present, and that AIO on pipes is no longer >> supported." >> >> And this is from IDS 10: >> " >> >> Kernel Asynchronous I/O (KAIO) >> >> Asynchronous I/O is supported by the official Linux kernel since version >> 2.6.x. IBM Informix Dynamic Server supports Kernel Asynchronous I/O (KAIO) >> on character devices (a.k.a. raw devices) and */_block devices._/* It is enabled >> by default, and can be disabled by setting the environment variable >> KAIOOFF=1 in the environment of the process that brings up the server." >> >> >> >> >> Dimitar Bachvarov >> >> >> --------------000009060008040402080605 >> Content-Type: text/html; charset=ISO-8859-1 >> X-Google-AttachSize: 3049 >> >> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> >> <html> >> <head> >> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> >> </head> >> <body bgcolor="#ffffff" text="#000000"> >> <a class="moz-txt-link-abbreviated" href="mailto:ruediger.papke@t-online.de">ruediger.papke@t-online.de</a> wrote: >> <blockquote >> cite="mid1163327908.961797.96190@i42g2000cwa.googlegroups.com" >> type="cite"> >> <pre wrap="">Hi, >> >> i did some simple tests because of the performance of different file >> systems and raw device under suse linux 10.1 (uname -a: 2.6.13-4-smp) >> and ids10.00.UC4. >> >> I was not able to bind a block-device to a raw device with the >> raw-command. >> Is that right ??? >> >> So I handled the unmounted partition(no fs) /dev/sda12 as raw-device. >> >> All instances are identical (same onconfig except identification >> parameters). The instances were made from same archive with >> rename-option. >> >> I testet import-time of a database (real time of time-command): >> raw 23m11.4 >> ext2 23m16.8 >> ext3 30m0.4 >> xfs 32m37.8 >> reiser 53m6.1 >> >> the file systems and the raw partition are on the same SATA-disk >> (aprox. 300GB). >> my questions: >> the raw partition and ext2 are fastest, is it right, to handle >> /dev/sda12 like a raw partition (benefits,advantages)? >> I had no control over the position of the tracks. Is there a noticeable >> influence of track-position on performance? >> >> TIA >> ruediger papke >> >> _______________________________________________ >> Informix-list mailing list >> <a class="moz-txt-link-abbreviated" href="mailto:Informix-list@iiug.org">Informix-list@iiug.org</a> >> <a class="moz-txt-link-freetext" href="http://www.iiug.org/mailman/listinfo/informix-list">http://www.iiug.org/mailman/listinfo/informix-list</a> >> >> >> </pre> >> </blockquote> >> On Linux kernel 2.6.x raw dvices are obsolete.<br> >> This is from a RHEL 4 release notes:<br> >> "Although Red Hat Enterprise Linux 4 includes support for rawio, it is >> now a deprecated interface. If your application performs device access >> using this interface, Red Hat encourages you to modify your application >> to open the block device with the <span><b class="command">O_DIRECT</b></span> >> flag. The rawio interface will exist for the life of Red Hat Enterprise >> Linux 4, but is a candidate for removal from future releases. >> <p>Asynchronous I/O (AIO) on file systems is currently only supported >> in <span><b class="command">O_DIRECT</b></span>, or non-buffered mode. >> Also note that the asynchronous poll interface is no longer present, >> and that AIO on pipes is no longer supported."<br> >> </p> >> <p>And this is from IDS 10:<br> >> "<br> >> </p> >> <pre>Kernel Asynchronous I/O (KAIO) >> >> Asynchronous I/O is supported by the official Linux kernel since version >> 2.6.x. IBM Informix Dynamic Server supports Kernel Asynchronous I/O (KAIO) >> on character devices (a.k.a. raw devices) and <b><i><u>block devices.</u></i></b> It is enabled >> by default, and can be disabled by setting the environment variable >> KAIOOFF=1 in the environment of the process that brings up the server." >> >> >> >> </pre> >> <p>Dimitar Bachvarov<br> >> </p> >> </body> >> </html> >> >> --------------000009060008040402080605-- >> > > > I was just about to start a thread regarding what to choose for IDS > 9.40 or 10 on Linux. In SuSE releases with 2.4.21 kernels I used raw > devices and was satisfied. But I did hear somewhere that raw access > will be dessuported. > > Is it possible that raw devices will be supported in some distros (e.g. > SuSE) and not in others, or the feature will be completely removed from > further Linux development? Why? I seem to remember that Mr Torvald > Linus was not proponent of raw devices, so that feature was included > rather lately (in kernel 2.2?). Is it wise to start using file systems > for IDS storage with 2.6 kernels now? (I prefer raw devices whenever > possible. I don't agree that it makes administration harder or more@@N
Related threads
- Conversion to differeent characters sets
- Problem in changing locale via dbexport/dbimport
- RE: openlink error "Unable to load locale categories"