Since fsck takes a lot of time to complete, we have disabled fsck which runs based on mount counts and duration between the mounts using tune2fs command as follows.

tune2fs -c 0 -i 0 <file_system>.

To ensure filesystem consistency even across unclean shutdowns, we are planning to enable journal to the file system using tune2fs -O has_journal option.

My question is, will enabling file journal has any performance issue. Since all the disk transaction has to be logged to journal will it not take more time?

Thanks in advance.

Hi,

as an easy answer, yes, enabling journal will have an impact on performance. The question is, how much in your use case.
And is this performance issue lower than the risk of loosing data.

So we all don't know anything about your system and the usage, so we will be unable to provide you with kind of advice. If we are talking about a small webserver, so fsck time will be also small. If you are running a companies file server providing 25 TB of data the fsck time can take up to 2 or 3 days.

From my point, disabling fsck is bad idea. The checks are made to prevent from data loss, so better you enable it. Also in most cases journaling does not have a measurable impact on most systems.

To get a decision point calculate what does have higher priority for your business, Data loss or little smaller IO performance.

I am not sure you have the right understanding about what you are about to do. What fs are you using that is not already using journal? All the main linux fs's do use journal by default, except ext2. Are you truly using ext2?

Second, journal IS NOT a substitute for disk checking. The journal is a way to shorten fsck, but it's not a substitute for it. In fact, it's fsck the one that will replay your journal after a hard reboot to restore the fs to a properly working state, and if further checking is needed, it will be done.

Each fs performs differently for different tasks. Journaling takes a bit of cpu and can make *some* operations slightly slower, but in the contrary it will radically shorten some others, like checking and repairing the fs. It will also help to maintain the integrity of your data.



If you are truly bothered by this, I'd try using another fsck policy, but completely getting rid of it can have consequences There are ways to run fsck at shutdown instead, maybe you prefer that. I know it's possible, but never bothered with that.

We are using ext3. By default has_jounal is enabled. But what I am mean by enabling journal is, I am mounting the file system with journal_data enabled, in which case it add even data(not just meta data) to jornal.

I see, that makes more sense. You might be interested in this article.

http://www.ibm.com/developerworks/li...y/l-fs8.html#4

With journaling enabled you're already double tapping the disk. So when you mount with journal=data and do a full double write expect your 'svctm' metric to rise, but since you're already journaling, the overall performance shouldn't ( I say this from a 1000 foot view) be impacted too much beyond what you have now.

Obviously you are more paranoid about data loss than disk service times.

UPDATE: If you want to NOT impact performance or improve the mount performance, convert the ext3 to an ext2 and then re-create the journal on another file systems of equal or greater speed. This way you'll be single hitting the disk and the journal and likely GREATLY improving the performance of your main data volume and preserving the data (not just the metadata) on the independent volume.