Allow journaling freeze when a journal I/O error occurs.
When FreezeOnError=0 (false, the default), InterSystems IRIS does not freeze journaling on a journal file I/O error. This option keeps the instance available, but exposes it to potential data loss.
The journal daemon retries the failed operation periodically (typically at one second intervals) until either it succeeds, or journaling is disabled because the instance cannot buffer any further journaled updates or a predetermined time limit (typically 150 seconds) has been reached.
When journaling is disabled, you should back up your databases as soon as possible. Continuing without journaling is a calculated risk, as it means the activity that occurs during this period cannot be restored.
Once journaling has been disabled, you must manually restart it, which you can do by running the ^JRNSTARTOpens in a new tab routine or selecting option 1, Begin Journaling, from the ^JOURNALOpens in a new tab routine menu.
When FreezeOnError=1 (true), InterSystems IRIS immediately freezes all journaled global updates when a journal file I/O error occurs. Global updates are also frozen if the journal daemon has been unable to complete a journal write for at least 30 seconds. This option protects the instance against data loss, but makes it less available or unavailable while the problem is being resolved.
The journal daemon retries the failed I/O operation and unfreezes global updates after it succeeds. Meanwhile, the freezing of global updates causes other jobs to hang. The typical outcome is that InterSystems IRIS hangs until you resolve the journaling problem, with the system appearing to be down to operational end-users. While InterSystems IRIS is hung you can take corrective measures, such as freeing up disk space, switching the journal to a different disk, or correcting a hardware failure.
For further details, see Journal I/O Errors in the Data Integrity Guide.