UFS UFS file system with/without journaling. Which is better?

I think journaling in general is more of a recoverability item. Basically changes to the filesystem flow through the journal and if the system crashes before changes get written to disk, on reboot the system can replay the journal and make the filesystem consistent.
I've seen cases written about where recovering a USF filesystem without a journal would take "a long time" but with a journal recovery was "minutes". I think the size of the filesystems was on order of terrabytes, so journal/not journal ask:

How big are the filesystems
What kind of operations for the typical use case (mostly read because streaming data or mostly writes because lots of people changing things)

I'm not sure if there is a performance penalty by using a journal. Logically I'd say "yes" but "how much" would be the next question.
 
The UFS2 journal only tracks freed space, as soft-updates handles the rest. You can use soft-updates without a journal, reducing writes to a SSD, for example. But any freed space that isn't written to metadata when power fails will remain allocated but unassigned until an fsck is performed. The journal will leave less work for fsck after a power failure, meaning the boot will take less time.

This is unlike Linux filesystems, IBM's JFS, and ZFS which write every metadata write to the journal before committing for real to the filesystem. UFS2 will only use the journal for any consistency that soft-updates cannot handle.

No user data is written to the journal.
 
If you don't do journaling you probably have synchronous metadata on. That is slow when you operate on many files.

The only reason I can think of to keep it off is when you might want to mount the filesystem from other OSes in the future.
 
softupdate+journaling is slower due to additional writes.
Especially with HDD.
On SSD, the time taken for fsck is acceptable even without journaling.
It is a good idea to measure and decide how long it will take.

For performance on HDD, gjournal is the way to go.
The performance difference is obvious when large compressed files are extracted to the same HDD.
The problem is that the OS crashes when the journal overflows.
For this reason, the size of the provider for the journal needs to be increased on machines with a lot of memory.

Edit:Added blank line.
 
Charlie_ said:
softupdate+journaling is slower due to additional writes.
Click to expand...

Not 100% correct. For su+j, only file deletes are written to the journal. The rest are handled by softupdates.

Though, gjournal is a different animal. It behaves like any Linux ext4 journal.

Charlie_ said:
Especially with HDD.
On SSD, the time taken for fsck is acceptable even without journaling.
It is a good idea to measure and decide how long it will take.
For performance on HDD, gjournal is the way to go.
Click to expand...
Why?

Soft-updates orders writes in memory while su+j uses the journal to only track deletes.

gjournal(8) is a similar technology found in ext4. Unlike soft-updates or su+j, every metadata write is journaled.

fsck is a bear on any UFS filesystem. OTOH when using su+j fsck takes mere seconds.
 
cy@ said:
Not 100% correct. For su+j, only file deletes are written to the journal. The rest are handled by softupdates.
Click to expand...
SU+J is slower than SU.
Su+j is never faster than su.
In some cases, of course, they may be equivalent.

‘For performance on HDD, gjournal is the way to go. ‘
This has nothing to do with fsck and everything to do with performance.
I don't see the point of including it and quoting it.

su+j does not always succeed fsck using the journal.
 
Charlie_ said:
SU+J is slower than SU.
Su+j is never faster than su.
In some cases, of course, they may be equivalent.

‘For performance on HDD, gjournal is the way to go. ‘
This has nothing to do with fsck and everything to do with performance.
I don't see the point of including it and quoting it.

su+j does not always succeed fsck using the journal.
Click to expand...
That depends on your workload. See https://people.freebsd.org/~pjd/pubs/gjournal.pdf.

And I saw some bonnie benchmarks by vermaden a number of years ago that showed UFS w/o GJ performed better in some cases while GJ was better for others. You can't make blanket statements like this.

We also need to keep in mind that su+j, ZFS, EXT3/4, XFS, JFS and BTRFS journal metadata only. Gjournal is a block level journal. It journals everything. Metadata and data. Yes, with GJ there is less loss of data because *everything* is journaled. But at the cost of potentially two physical writes for each block written.
 
cy@ said:
But at the cost of potentially two physical writes for each block written.
Click to expand...
This was a problem in the early days, but I don't recall experiencing it.
We have seen talk of corrective action but do not know if it has been completed.
Is this actually still a problem today?

Edit:
An fsck using su+j journal may not necessarily succeed if the HDD on which the writes are actually taking place is powered down.
In this case a normal fsck is performed.
Of course, if the HDD has no writes, fsck will be terminated immediately.
Is there enough confidence in the journal to recommend su+j instead of su on HDD that are constantly being written to?
 
Charlie_ said:
This was a problem in the early days, but I don't recall experiencing it.
We have seen talk of corrective action but do not know if it has been completed.
Is this actually still a problem today?

Edit:
An fsck using su+j journal may not necessarily succeed if the HDD on which the writes are actually taking place is powered down.
In this case a normal fsck is performed.
Of course, if the HDD has no writes, fsck will be terminated immediately.
Is there enough confidence in the journal to recommend su+j instead of su on HDD that are constantly being written to?
Click to expand...
With su+j, the journal is only written to when files or directories are delete. That's it. Soft-updates handles metadata writes, that's all. All data writes are not journaled. Constant writes of data to soft-updates is the same as constant writes w/o soft-updates. The only difference is when metadata is written (including indirect blocks).

If you want all data writes journaled too, gjournal is your only option.

Can soft-updates handle lots of data writes? Yes, because soft-updates only handles metadata?

If you want to journal user data as well, then use gjournal. Their paradigms are different.

Talking about different paradigms, all other filesystems, i.e. EXT3/4, XFS, NTFS, JFS, BTRFS, and ZFS, only use the journal for metadata writes, just like su+j does with (file deletes). None of them journal user data like gjournal does. Again, if you want the protection of user data journaling, use gjournal.
 
What is the point of quoting my post in that story?
It doesn't seem relevant to my question.

If there are not many writes to the file system, su+j is recommended.
If writing is continuous, I recommend su instead of su+j.
 
You must log in or register to reply here.
Back
Top