As many of you know, RH dropped support for raw devices starting in RH9. I know, I know - they've dropped support in the past and then added it back in. This time, so far as I know, they have not added it back. One source claimed that Linus finally got his way and support for raw was removed from the Linux kernel that is used in RH9 and later. That would imply that other Linux distributions also will lose support for raw devices as they migrate to that version (or later) of the kernel.
So we're going to have to migrate from raw to cooked. Some of our instances will be migrated by doing a level 0 archive of the raw environment, shutting down, creating cooked chunks, and restoring to those cooked chunks. Other instances will create mirror chunks on cooked files, then swap raw primary and cooked mirror chunks, then drop the raw chunks.
I've viewed Art Kagel's presentation on the various Linux file system types. Based on that, it looks like XFS is the best choice we have on RH9.
On raw devices, we frequently had multiple chunks on the same device, using the '-o' option in onspaces to specify an offset. We will not be doing that when we moved to cooked, as we'll be using a separate cooked file for each chunk.
My questions today are about the best practices for cooked chunks. First, how many file systems should we create? Does it matter if we use just one file system for all Informix cooked chunks, or should we create multiple? If multiple, how many? Does it vary based on the number of chunks, or the total size of the file system, or one file system per dbspace, or some other factor? Does Linux spread I/O across multiple file systems in some way?
Are there specific parameters that need to be used for mkfs.xfs when setting up the file systems? Does the block size need to match the dbspace page size? Does the sector size need to match page size? Is there any performance benefit to specifying fewer inodes (assuming we'll only have a few dozen chunks in the file system)? Do we need to specify any '-m' (global metadata option) -d (data section options), or '-l' (log section options)? I need to know what to tell our Linux sys admin if we need anything other than the defaults.
Next up - when it comes time to actually allocate a cooked file for a chunk, I know that if the instance is running and we run 'onspaces -c -d dbspace_name -p /path/to/cooked/file -o 0 -s 5000000', Informix will create the file and fill it up to the specified size. For the situation where we are going to restore an archive to the cooked files, is there any advantage to us manually filling the files to the correct size via 'dd' or some similar utility? I'm thinking back to the days of DOS computers where the files would start of small and then grow, leading to fragmentation on the disk, and I'm trying to prevent something like that from happening here. Thinking that if the file is already the correct size when the restore runs, it will just use the existing space.
Am I overthinking things here? Everything these days is virtualized, with VMs using space that SAN administrators carve up and distribute to the various hosts. With all of these layers of abstraction, it seems impossible to structure the layout for performance like we did in the old days. Given that, should I just create the zero-byte files and let the OS and the SAN just decide where to put things?
One last question - of the platforms that current versions of Informix run on, which ones are left that still support raw devices, now that Linux has eliminated them?
Thanks in advance.
------------------------------
mark collins
------------------------------