Again, responding inline:
A couple of follow-up questions based on your response:
We're in agreement on the separate file for each chunk (as you acknowledged in your response), and I was expecting to use the EXTENDABLE option as well. My Linux sys adm (and most sys adms I've worked with over the years) say that there are performance / reliability issues if you let a file system get near 100% used.
I cannot directly comment on that, not a storage admin after all. Just thinking about it, I would imagine the concern is because such a filesystem would normally be heavily fragmented due to files being deleted and other added that might be larger or smaller leaving many small holes. If that is it, then not a problem since you will not likely be dropping chunks. Yes, multiple chunks might be extending over time interleaving their new extents, however, the xfs_fsr utility can defragment an XFS filesystem while online, so ...
Do you have any thoughts on how close to 100% used we can get in an XFS file system, assuming that it only contains database cooked files? Is there a parameter that we can use to automatically disable the EXTENDABLE option on specific chunks when the file system approaches that limit? Or do we have to code that via a script or a scheduled task to check the %used in a file system and then disable the EXTENDABLE option at that time?
You could set a storage pool for the dbspace setting the total size of the FS a bit below 100% as recommended by your SAs, but that will only affect new chunks, not extendability. You will have to monitor to FS externally with a daily or hourly cron and manually add a chunk to dbspaces nearing fullness either via onspaces or using the storage pool.
With storage being a bit abstracted these days, it's hard to know for certain what physical devices contain which bit of storage, or even which servers are storing data on a particular physical device. But I take your point that at least to the OS, they'll look like different devices and so the IOs will be parallelized as far as the OS is concerned. How those IOs actually make it to the final device(s) then becomes the responsibility of the SAN, which may result in IOs not being as parallelized as it appears to the OS.
Exactly. Best we can do if we don't want to go back to JBOD.
Art
------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com------------------------------
Original Message:
Sent: Fri May 08, 2026 12:20 PM
From: mark collins
Subject: Question on file systems for cooked files
Hi Art,
A couple of follow-up questions based on your response:
I would strongly recommend that you rather create a file for each chunk with one chunk per dbspace (at least until the filesystem fills up). That makes chunk management SO much easier. It allows you to mark your chunks as EXTENDABLE and just let them grow automatically instead of having to keep adding more and more chunks to grow the dbspaces.
We're in agreement on the separate file for each chunk (as you acknowledged in your response), and I was expecting to use the EXTENDABLE option as well. My Linux sys adm (and most sys adms I've worked with over the years) say that there are performance / reliability issues if you let a file system get near 100% used. Do you have any thoughts on how close to 100% used we can get in an XFS file system, assuming that it only contains database cooked files? Is there a parameter that we can use to automatically disable the EXTENDABLE option on specific chunks when the file system approaches that limit? Or do we have to code that via a script or a scheduled task to check the %used in a file system and then disable the EXTENDABLE option at that time?
Yes. Just place each file system on a different device like you are doing now. That allows the OS to schedule IOs in parallel as Informix will do for dbspaces.
With storage being a bit abstracted these days, it's hard to know for certain what physical devices contain which bit of storage, or even which servers are storing data on a particular physical device. But I take your point that at least to the OS, they'll look like different devices and so the IOs will be parallelized as far as the OS is concerned. How those IOs actually make it to the final device(s) then becomes the responsibility of the SAN, which may result in IOs not being as parallelized as it appears to the OS.
Thanks.
------------------------------
mark collins
------------------------------
Original Message:
Sent: Fri May 08, 2026 06:47 AM
From: Art Kagel
Subject: Question on file systems for cooked files
Mark:
I'm going to answer your questions inline below:
ince support for raw devices was removed in RH 9, we're starting the process of migrating on non-prod instances to cooked files. I've got a few questions now, and likely will have more in the future.
First, as I understand from a presentation Art did a few years ago, the preferred file system type on RHEL 9 is XFS. Is that correct?
Definitely one of the preferred filesystems, yes. Relatively low overhead, safe.
I know that Ben suggested looking at ZFS. I'm not a fan. While it is also relatively low overhead and safe, it is a copy-on-write filesystem which can accelerate the wear-down of SSD drives which are performing copy-on-write under the hood anyway resulting on two physical copies at the drive level.
When creating the file system, are there any file system options that we should consider, or should we just use the defaults? For instance, should we use the '-b' block size options to set the block size to 2048 to match the default Informix page size? Or is there another value that is more appropriate or gives better performance? Since the database will reside in a relatively small number of large cooked files, should we try to tweak the '-i' inode options to allocate fewer inodes, resulting in fewer bytes going to file system overhead?
The above sounds like you are planning to allocate multiple chunks within a single file, similarly as you might have done on RAW devices. I would strongly recommend that you rather create a file for each chunk with one chunk per dbspace (at least until the filesystem fills up). That makes chunk management SO much easier. It allows you to mark your chunks as EXTENDABLE and just let them grow automatically instead of having to keep adding more and more chunks to grow the dbspaces.
Making the block size 2K would probably be a good idea. That would minimize SSD block cleanup.
Any other mkfs.xfs options that we should change?
Can't think of any, but, as Ben suggested, look it up. Opening a PMR to get advice couldn't hurt.
Is there any advantage to having multiple file systems vs a single file system? For example, a file system for logical logs, another for table dbspace(s), another for index dbspace(s), another for physical log, etc., vs a single file system with separate directories for logical logs, physical logs, table dbspaces, index dbspaces, temp dbspaces, etc.? Or should we just make a single directory and have all of the cooked files reside in that one directory, with just the file names identifying which are for logical logs, physical logs, temp dbspaces, etc.?
Yes. Just place each file system on a different device like you are doing now. That allows the OS to schedule IOs in parallel as Informix will do for dbspaces.
We do plan on having a separate cooked file for each chunk, rather than using offsets within files.
Ahh, missed that on my first read-through. Agreed, obviously.
That all of the questions I can think of at the moment, but I know I'll have more as we move forward.
Art
Feel free to tell me that I'm overthinking this and I should just accept all of the defaults. It's just hard to do that after decades of trying to optimize placement of data across different raw disks.
------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com