Some Informix DBAs believe "journaling" should be turned off for file systems that hold Informix chunks. The idea is that Informix does its own journaling, so the operating system journaling is unnecessary and possibly harmful.
We are using the ext4 file system type on our Linux machines. It has advantages over prior types ext2 and ext3 in that it allows larger files to be stored.
Here is an article about how to know which type of file system is being used:
Here is an article about how to turn off journaling for an ext4 file system partition:
I'm hoping I can get some more comments on this subject. Does anyone know of documentation from an official IBM / Informix source on whether file system journaling should be off? If so, I want to share it with our Operations staff, because they are preparing a new machine that will have an Informix database.
John Dargan, Database Administrator II - Information Technology
LAURA E. ROTH, Clerk of the Circuit Court
Seventh Circuit, Volusia County, Florida
You can also consider xfs as a valid option. Art Kagel has been looking deep into that option and it seems to present many advantages, in addition to being a more current technology
Eric VercellettoData Management Architect and Owner / Begooden IT ConsultingKandooERP Founder and CTOIBM Champion 2013,2014,2015,2016,2017,2018,2019,2020
Tel: +33(0) 298 51 3210Mob : +33(0)626 52 50 68skype: begooden-itGoogle Hangout: email@example.comEmail: firstname.lastname@example.org : http://www.vercelletto.comwww https://kandooerp.org
The last time I tested this – a year ago – in the customer environment ext2 was still the faster of all the ext*, xfs examined. However, they settled on xfs due to the ease of admin
Some thoughts on this subjects maybe not directly related to the question whether to use "journaling" or not.
Recent hardware saw significant improvements in CPU processing capabilities, amounts of available memory and even disk performance - if we take into account (enterprise) SSD, NVMe, or all-flash storage. With current hardware, in my opinion, the emphasis needs to be made either on avoiding I/O as much as possible (larger buffer pool) or using all-flash storage solutions to have "balanced" configuration that would take full advantage of the increased CPU power. Otherwise, as soon as Informix touches disk (aside from logging) - performance would be greatly impacted, with fairly little difference of whether the file system is journalled or not.
On the matter of turning off journaling for ext4 or other FS. Journaling mostly comes into play when the system goes down unexpectedly due to sudden power loss. In such case - after restart - without journal there will be a need to run file system check (fsck - executed before system can mount the fs) which can take long time, depending on the underlying storage speed and size/contents of the file system. Note that Informix logging is not a replacement for FS journal - Informix will not even be able to access the logs and start it's recovery until the file system is made consistent by fsck and mounted. Sometimes fsck will fail - and require administrator's assistance to make a decision - so the system may not even come up without intervention from the operator.Journaled files system, from practical experience, takes seconds to replay log when restarted after crash, and system becomes alive much faster.
Therefore - if system can never crash - yes, the journal can be safely disabled, and yes, it will result in (slightly) improved I/O performance. However any significant amount of I/O will slow down RDBMS, journal or no journal, unless storage is really fast (NVMe or all-flash) and in that case overhead from journaling is also negligible.Note that "raw devices" don't have these problems (unless write cache to storage device is enabled without equivalent of battery backup)To conclude - for overall safety reasons, personally I'd avoid turning off journal. If I/O is a problem - just use adequate amount of memory for the Informix buffer pool (+ direct I/O, of course), if there is still not enough RAM and I/O significantly affects performance - consider investing into all-flash storage.
If they are preparing a machine for you then you have an opportunity to some testing .... And then argue from a position of having data.