RE: Informix: Informix cooked files filesystem layout

Hello, Thank you both for your answers. @Art: Actually the instance is configured already similarly to the way you described: Dbspaces address number flags fchunk nchunks pgsize flags owner name 4bb61028 1 0x1 1 1 2048 N BA informix rootdbs 4bdf3660 2 0x2001 2 1 2048 N TBA informix tempdbs 4bdf38a0 3 0x1 3 1 2048 N BA informix physdbs 4bdf3ae0 4 0x1 4 1 2048 N BA informix logdbs 4bdf3d20 5 0x8001 5 1 2048 N SBA informix sbspace 4c5f5028 6 0x1 6 1 2048 N BA informix admindbs 4c5f5268 7 0x1 7 1 16384 N BA informix sopradbs 7 active, 2047 maximum Chunks address chunk/dbs offset size free bpages flags pathname 4bb61268 1 1 0 150000 110812 PO-B-- /IDS/rootdbs_chk01 4c5f54a8 2 2 2 10239998 9731845 PO-B-- /IDS/tempdbs_chk01 4c5f6028 3 3 2 10239998 2375625 PO-B-- /IDS/physdbs_chk01 4c5f7028 4 4 2 15359998 11984945 PO-B-- /IDS/logdbs_chk01 4c5f8028 5 5 2 1023998 955002 955002 POSB-- /IDS/sbspacesdbs_chk01 Metadata 68943 51302 68943 4c5f9028 6 6 2 511998 424720 PO-B-- /IDS/admindbs_chk01 4c5fa028 7 7 8 39321343 33202348 PO-B-- /IDS/sopradbs_chk01 In the current disk layout all system dbspaces (all except sopradbs in the output above) are lvs created in the same volume group and sopradbs (data dbspace) is created on a different volume group. So i was wondering if the change from raw device to cooked files is not related to how the filesystem(s) should be structured or if there is something that i need to keep in mind for production systems. In a testing environment that is used only for dbexport and backup purposes i just migrated all chunks to the same filesystem and the instance is fine. But in this case there is no application accessing the database so it is not comparable to a production server. @Henri@Art: Actually i read about DIRECT_IO in a similar thread opened in the community (see below) raw disk support deprecated in RHEL 9.x | Informix <https://community.ibm.com/community/user/discussion/raw-disk-support-deprecated-in-rhel-9x>; In this thread, the following was mentioned: "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" With that in mind i am wondering what the most "conservative" approach would be, meaning if i should start without DIRECT_IO and use it if i noticed any performance issues or if it would be better to set it up in the same day of the migration from raw disks to cooked files. Best Regards, Stavros You are subscribed to "Informix" as paul.cdi@oninit.com. To change your subscriptions, go to http://community.ibm.com/community/user/preferences?section=Subscriptions. To unsubscribe from this community discussion, go to [link removed]