I have been informed by my RH sysadm that support for raw disk has been deprecated in RHEL 9.x (specifically RH 9.5).  He says that they have gone so far as to remove all information from the man pages.

As we currently have our Informix instances on raw disks, I wanted to see whether anyone else has encountered this.  Are there any workarounds to continue using raw disk on RHEL 9.x?  If not, what "gotchas" do I need to be aware of for converting the existing raw instances to use cooked disk?  Things like specific file system types to use, any changes to kernel settings to minimize double buffering or other things that would impact performance.

Thanks in advance.

Mark

Mark:

Yea, RH and a few other distributions have been trying to eliminate RAW disk on Linux forever. I think that this is the fourth time that RH has deprecated RAW support. Until now it has always reappeared after a time. In the past it was also possible to manually install the RAW device support yourself. Not sure it will come back this time. Rumor has it that RH finally removed the hooks that the RAW modules used, but rumor ...

All that said, with the advent of DIRECT_IO the main reasons for using RAW, the improved performance by eliminating file system overhead and double buffering, are no long major issues. With DIRECT_IO the performance hit versus RAW is down from 20-25% to barely 5% and sometimes less. 

However, that has been highly variable and I don't think anyone has figured out what effects the performance. Some systems do not perform any better with DIRECT_IO enabled than with it disabled using file system chunks and some even perform better without DIRECT_IO. So, you should do some major testing with a substantially identical host and storage with as close to the production database and operations as possible.

As far as file systems to use: Here's a link to a WAIUG meeting where I did one of my presentations on storage in which I discuss different file system:
WAIUG Part 1 - Welcome and Doing Storage Better by Art Kagel

YouTube		remove preview
WAIUG Part 1 - Welcome and Doing Storage Better by Art Kagel WAIUG Meeting Part 1. Welcome by Thomas Beebe and Doing Storage Better - Exploring the best and worst options by Art Kagel View this on YouTube >

There are two best way to migrate your data from RAW to COOKED file system chunks:

1 - If you have used symbolic links for chunk paths, you can just shut the engine down, break the links and point them to physical file system files, copy the RAW chunks to the new files, and restart the instance. This, of course, entails long downtime.

2 - If you are running v14.10 or later you can use the mirror swapping feature by mirroring your RAW chunks to file system files (also an opportunity to break up chunks built as ranges of space in a single RAW device into separate files, simplifying maintenance and allowing you to make chunks extendable). Once the mirrors have synced you can swap the primary (RAW) chunk with the new mirror chunk then drop the mirror chunks which are now the RAW chunks. This entails no downtime just some performance hit during the copies which you can do one chunk at a time if you need to minimize the impact.

Art

I have been informed by my RH sysadm that support for raw disk has been deprecated in RHEL 9.x (specifically RH 9.5).  He says that they have gone so far as to remove all information from the man pages.

As we currently have our Informix instances on raw disks, I wanted to see whether anyone else has encountered this.  Are there any workarounds to continue using raw disk on RHEL 9.x?  If not, what "gotchas" do I need to be aware of for converting the existing raw instances to use cooked disk?  Things like specific file system types to use, any changes to kernel settings to minimize double buffering or other things that would impact performance.

Thanks in advance.

Mark

Hi Art,

Yeah, I know that Linus has been trying to rid the world of raw devices for many years.  And I thought that I recalled a couple of previous attempts to remove raw disk support from RH, only to reverse course and allow it to continue.

On the topic of symbolic links, can I:

1. Take a level 0 archive on the existing instance;
2. Stop the instance;
3. Change symbolic links to point to cooked files;
4. Perform a physical restore from the level 0 archive

or were you proposing that I copy the data from raw to cooked via something like the dd utility?

And thank you for the copy of your presentation.  I'll be looking through it in the upcoming days and may have some follow-up questions

Mark

Mark:

Yea, RH and a few other distributions have been trying to eliminate RAW disk on Linux forever. I think that this is the fourth time that RH has deprecated RAW support. Until now it has always reappeared after a time. In the past it was also possible to manually install the RAW device support yourself. Not sure it will come back this time. Rumor has it that RH finally removed the hooks that the RAW modules used, but rumor ...

All that said, with the advent of DIRECT_IO the main reasons for using RAW, the improved performance by eliminating file system overhead and double buffering, are no long major issues. With DIRECT_IO the performance hit versus RAW is down from 20-25% to barely 5% and sometimes less. 

However, that has been highly variable and I don't think anyone has figured out what effects the performance. Some systems do not perform any better with DIRECT_IO enabled than with it disabled using file system chunks and some even perform better without DIRECT_IO. So, you should do some major testing with a substantially identical host and storage with as close to the production database and operations as possible.

As far as file systems to use: Here's a link to a WAIUG meeting where I did one of my presentations on storage in which I discuss different file system:
WAIUG Part 1 - Welcome and Doing Storage Better by Art Kagel

YouTube		remove preview
WAIUG Part 1 - Welcome and Doing Storage Better by Art Kagel WAIUG Meeting Part 1. Welcome by Thomas Beebe and Doing Storage Better - Exploring the best and worst options by Art Kagel View this on YouTube >

There are two best way to migrate your data from RAW to COOKED file system chunks:

1 - If you have used symbolic links for chunk paths, you can just shut the engine down, break the links and point them to physical file system files, copy the RAW chunks to the new files, and restart the instance. This, of course, entails long downtime.

2 - If you are running v14.10 or later you can use the mirror swapping feature by mirroring your RAW chunks to file system files (also an opportunity to break up chunks built as ranges of space in a single RAW device into separate files, simplifying maintenance and allowing you to make chunks extendable). Once the mirrors have synced you can swap the primary (RAW) chunk with the new mirror chunk then drop the mirror chunks which are now the RAW chunks. This entails no downtime just some performance hit during the copies which you can do one chunk at a time if you need to minimize the impact.

Art

I have been informed by my RH sysadm that support for raw disk has been deprecated in RHEL 9.x (specifically RH 9.5).  He says that they have gone so far as to remove all information from the man pages.

As we currently have our Informix instances on raw disks, I wanted to see whether anyone else has encountered this.  Are there any workarounds to continue using raw disk on RHEL 9.x?  If not, what "gotchas" do I need to be aware of for converting the existing raw instances to use cooked disk?  Things like specific file system types to use, any changes to kernel settings to minimize double buffering or other things that would impact performance.

Thanks in advance.

Mark

Mark:

Yes, you can do a restore of an archive after relinking your symbolic chunk links from the raw devices to file system files. It will require roughly the same downtime as doing the copies using dd (yes I was thinking of using dd).

Are you still on v12.10 or earlier? Given that v12.10 is going out-of-support at the end of April 2026 and older releases are already out-of-support, I would recommend that anyone on an older release upgrade to v14.10 ASAP and plan to upgrade to v15.0 sometime in late 2026 or in 2027 once it is completely stable. Once you are on a currently developed release, you can do the mirror swap thing and avoid any downtime at all.

Art

Hi Art,

Yeah, I know that Linus has been trying to rid the world of raw devices for many years.  And I thought that I recalled a couple of previous attempts to remove raw disk support from RH, only to reverse course and allow it to continue.

On the topic of symbolic links, can I:

1. Take a level 0 archive on the existing instance;
2. Stop the instance;
3. Change symbolic links to point to cooked files;
4. Perform a physical restore from the level 0 archive

or were you proposing that I copy the data from raw to cooked via something like the dd utility?

And thank you for the copy of your presentation.  I'll be looking through it in the upcoming days and may have some follow-up questions

Mark

Mark:

Yea, RH and a few other distributions have been trying to eliminate RAW disk on Linux forever. I think that this is the fourth time that RH has deprecated RAW support. Until now it has always reappeared after a time. In the past it was also possible to manually install the RAW device support yourself. Not sure it will come back this time. Rumor has it that RH finally removed the hooks that the RAW modules used, but rumor ...

All that said, with the advent of DIRECT_IO the main reasons for using RAW, the improved performance by eliminating file system overhead and double buffering, are no long major issues. With DIRECT_IO the performance hit versus RAW is down from 20-25% to barely 5% and sometimes less. 

However, that has been highly variable and I don't think anyone has figured out what effects the performance. Some systems do not perform any better with DIRECT_IO enabled than with it disabled using file system chunks and some even perform better without DIRECT_IO. So, you should do some major testing with a substantially identical host and storage with as close to the production database and operations as possible.

As far as file systems to use: Here's a link to a WAIUG meeting where I did one of my presentations on storage in which I discuss different file system:
WAIUG Part 1 - Welcome and Doing Storage Better by Art Kagel

YouTube		remove preview
WAIUG Part 1 - Welcome and Doing Storage Better by Art Kagel WAIUG Meeting Part 1. Welcome by Thomas Beebe and Doing Storage Better - Exploring the best and worst options by Art Kagel View this on YouTube >

There are two best way to migrate your data from RAW to COOKED file system chunks:

1 - If you have used symbolic links for chunk paths, you can just shut the engine down, break the links and point them to physical file system files, copy the RAW chunks to the new files, and restart the instance. This, of course, entails long downtime.

2 - If you are running v14.10 or later you can use the mirror swapping feature by mirroring your RAW chunks to file system files (also an opportunity to break up chunks built as ranges of space in a single RAW device into separate files, simplifying maintenance and allowing you to make chunks extendable). Once the mirrors have synced you can swap the primary (RAW) chunk with the new mirror chunk then drop the mirror chunks which are now the RAW chunks. This entails no downtime just some performance hit during the copies which you can do one chunk at a time if you need to minimize the impact.

Art

I have been informed by my RH sysadm that support for raw disk has been deprecated in RHEL 9.x (specifically RH 9.5).  He says that they have gone so far as to remove all information from the man pages.

As we currently have our Informix instances on raw disks, I wanted to see whether anyone else has encountered this.  Are there any workarounds to continue using raw disk on RHEL 9.x?  If not, what "gotchas" do I need to be aware of for converting the existing raw instances to use cooked disk?  Things like specific file system types to use, any changes to kernel settings to minimize double buffering or other things that would impact performance.

Thanks in advance.

Mark

Mark:

Yes, you can do a restore of an archive after relinking your symbolic chunk links from the raw devices to file system files. It will require roughly the same downtime as doing the copies using dd (yes I was thinking of using dd).

Are you still on v12.10 or earlier? Given that v12.10 is going out-of-support at the end of April 2026 and older releases are already out-of-support, I would recommend that anyone on an older release upgrade to v14.10 ASAP and plan to upgrade to v15.0 sometime in late 2026 or in 2027 once it is completely stable. Once you are on a currently developed release, you can do the mirror swap thing and avoid any downtime at all.

Art

Hi Art,

Yeah, I know that Linus has been trying to rid the world of raw devices for many years.  And I thought that I recalled a couple of previous attempts to remove raw disk support from RH, only to reverse course and allow it to continue.

On the topic of symbolic links, can I:

1. Take a level 0 archive on the existing instance;
2. Stop the instance;
3. Change symbolic links to point to cooked files;
4. Perform a physical restore from the level 0 archive

or were you proposing that I copy the data from raw to cooked via something like the dd utility?

And thank you for the copy of your presentation.  I'll be looking through it in the upcoming days and may have some follow-up questions

Mark

Mark:

Yea, RH and a few other distributions have been trying to eliminate RAW disk on Linux forever. I think that this is the fourth time that RH has deprecated RAW support. Until now it has always reappeared after a time. In the past it was also possible to manually install the RAW device support yourself. Not sure it will come back this time. Rumor has it that RH finally removed the hooks that the RAW modules used, but rumor ...

All that said, with the advent of DIRECT_IO the main reasons for using RAW, the improved performance by eliminating file system overhead and double buffering, are no long major issues. With DIRECT_IO the performance hit versus RAW is down from 20-25% to barely 5% and sometimes less. 

However, that has been highly variable and I don't think anyone has figured out what effects the performance. Some systems do not perform any better with DIRECT_IO enabled than with it disabled using file system chunks and some even perform better without DIRECT_IO. So, you should do some major testing with a substantially identical host and storage with as close to the production database and operations as possible.

As far as file systems to use: Here's a link to a WAIUG meeting where I did one of my presentations on storage in which I discuss different file system:
WAIUG Part 1 - Welcome and Doing Storage Better by Art Kagel

YouTube		remove preview
WAIUG Part 1 - Welcome and Doing Storage Better by Art Kagel WAIUG Meeting Part 1. Welcome by Thomas Beebe and Doing Storage Better - Exploring the best and worst options by Art Kagel View this on YouTube >

There are two best way to migrate your data from RAW to COOKED file system chunks:

1 - If you have used symbolic links for chunk paths, you can just shut the engine down, break the links and point them to physical file system files, copy the RAW chunks to the new files, and restart the instance. This, of course, entails long downtime.

2 - If you are running v14.10 or later you can use the mirror swapping feature by mirroring your RAW chunks to file system files (also an opportunity to break up chunks built as ranges of space in a single RAW device into separate files, simplifying maintenance and allowing you to make chunks extendable). Once the mirrors have synced you can swap the primary (RAW) chunk with the new mirror chunk then drop the mirror chunks which are now the RAW chunks. This entails no downtime just some performance hit during the copies which you can do one chunk at a time if you need to minimize the impact.

Art

I have been informed by my RH sysadm that support for raw disk has been deprecated in RHEL 9.x (specifically RH 9.5).  He says that they have gone so far as to remove all information from the man pages.

As we currently have our Informix instances on raw disks, I wanted to see whether anyone else has encountered this.  Are there any workarounds to continue using raw disk on RHEL 9.x?  If not, what "gotchas" do I need to be aware of for converting the existing raw instances to use cooked disk?  Things like specific file system types to use, any changes to kernel settings to minimize double buffering or other things that would impact performance.

Thanks in advance.

Mark

And now for a follow-up.  If I try the level 0 restore approach, do I need to do anything to the cooked files prior to doing the restore?  Or can they just be 0 byte files from a "touch" command?  Assuming that the file system has sufficient space to accommodate the number of pages allocated to the chunk at the time of the level 0, I think I can just touch the files, make the symlinks, and do the restores, right?

Mark:

Yes, you can do a restore of an archive after relinking your symbolic chunk links from the raw devices to file system files. It will require roughly the same downtime as doing the copies using dd (yes I was thinking of using dd).

Are you still on v12.10 or earlier? Given that v12.10 is going out-of-support at the end of April 2026 and older releases are already out-of-support, I would recommend that anyone on an older release upgrade to v14.10 ASAP and plan to upgrade to v15.0 sometime in late 2026 or in 2027 once it is completely stable. Once you are on a currently developed release, you can do the mirror swap thing and avoid any downtime at all.

Art

Hi Art,

Yeah, I know that Linus has been trying to rid the world of raw devices for many years.  And I thought that I recalled a couple of previous attempts to remove raw disk support from RH, only to reverse course and allow it to continue.

On the topic of symbolic links, can I:

1. Take a level 0 archive on the existing instance;
2. Stop the instance;
3. Change symbolic links to point to cooked files;
4. Perform a physical restore from the level 0 archive

or were you proposing that I copy the data from raw to cooked via something like the dd utility?

And thank you for the copy of your presentation.  I'll be looking through it in the upcoming days and may have some follow-up questions

Mark

Mark:

Yea, RH and a few other distributions have been trying to eliminate RAW disk on Linux forever. I think that this is the fourth time that RH has deprecated RAW support. Until now it has always reappeared after a time. In the past it was also possible to manually install the RAW device support yourself. Not sure it will come back this time. Rumor has it that RH finally removed the hooks that the RAW modules used, but rumor ...

All that said, with the advent of DIRECT_IO the main reasons for using RAW, the improved performance by eliminating file system overhead and double buffering, are no long major issues. With DIRECT_IO the performance hit versus RAW is down from 20-25% to barely 5% and sometimes less. 

However, that has been highly variable and I don't think anyone has figured out what effects the performance. Some systems do not perform any better with DIRECT_IO enabled than with it disabled using file system chunks and some even perform better without DIRECT_IO. So, you should do some major testing with a substantially identical host and storage with as close to the production database and operations as possible.

As far as file systems to use: Here's a link to a WAIUG meeting where I did one of my presentations on storage in which I discuss different file system:
WAIUG Part 1 - Welcome and Doing Storage Better by Art Kagel

YouTube		remove preview
WAIUG Part 1 - Welcome and Doing Storage Better by Art Kagel WAIUG Meeting Part 1. Welcome by Thomas Beebe and Doing Storage Better - Exploring the best and worst options by Art Kagel View this on YouTube >

There are two best way to migrate your data from RAW to COOKED file system chunks:

1 - If you have used symbolic links for chunk paths, you can just shut the engine down, break the links and point them to physical file system files, copy the RAW chunks to the new files, and restart the instance. This, of course, entails long downtime.

2 - If you are running v14.10 or later you can use the mirror swapping feature by mirroring your RAW chunks to file system files (also an opportunity to break up chunks built as ranges of space in a single RAW device into separate files, simplifying maintenance and allowing you to make chunks extendable). Once the mirrors have synced you can swap the primary (RAW) chunk with the new mirror chunk then drop the mirror chunks which are now the RAW chunks. This entails no downtime just some performance hit during the copies which you can do one chunk at a time if you need to minimize the impact.

Art

I have been informed by my RH sysadm that support for raw disk has been deprecated in RHEL 9.x (specifically RH 9.5).  He says that they have gone so far as to remove all information from the man pages.

As we currently have our Informix instances on raw disks, I wanted to see whether anyone else has encountered this.  Are there any workarounds to continue using raw disk on RHEL 9.x?  If not, what "gotchas" do I need to be aware of for converting the existing raw instances to use cooked disk?  Things like specific file system types to use, any changes to kernel settings to minimize double buffering or other things that would impact performance.

Thanks in advance.

Mark