Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

I'm about to format an external hard disk drive (HDD).

What are the key differences between journaling HFS+ and non-journaling HFS+? Apart from the fact that one has journaling and the other does not, how does it affect the drive's performance (with numbers)?

My gut-feeling is that in "normal" use journaling would be the way to go, but are there any situations where non-journaling HFS+ should be considered? Linux compatibility is one, since it seems that the kernel's hfsplus module supports read & write on non-journaled HFS+, but only read on journaled HFS+.

Anything else worth mentioning?

share|improve this question

3 Answers 3

up vote 28 down vote accepted

I don't have numbers to back up the statement, but using HFS+ non-journaled is a good idea in certain volumes that require absolute speed, without worrying (too much) about a possible "data loss" or "data corruption" in case of power failure or similar.

When is using HFS+ Non-journaled a BAD idea?

  • External (USB, FW, ESata) drives that are connected and reconnected often: It's usually a bad idea, since these drives tend to be accidentally disconnected very often and or their power sources unplugged.

  • Partitions where data integrity is important and protection from an unexpected power loss is a must. (Documents, Music, Videos, Backups, etc).

When is using HFS+ Non-journaled a GOOD idea?

  • Scratch, Temp, trivial storage and similar drives and partitions, where speed is > data integrity in case of power fail. You want your Final Cut scratch volume to be non-journaled (you do have an UPS anyway, don't you?). You want your Photoshop temp to be non-journaled. Drives to copy stuff around (a Pen drive for example if you take care of properly ejecting).

  • Any other drive that requires portability and compatibility like you correctly pointed out.

Remember, maintaining the journal adds a small overhead, but the benefit in case of improper volume dismount are important, no only to avoid a full disk "scan" at startup or re-mount, but also in terms of making sure that data is not corrupted in the first place.

Mounting a non-journaled drive that has been incorrectly unmounted, will cause a fsck scan, whereas the journaled drive will be able to be up and running in a shorter period of time (scanning the journal and applying uncommited transactions).

Regarding Speed and tests, I don't have much info to back up the above claim, however, as far as I know the speed difference not only is very small and even hard to notice, but in some case Journaled filesystem is faster than non-journaled.

Turn out that despite the overhead of the journal, some operations can be made asynchronously in the Journaled drive, whereas the non-journaled version has to perform things synchronously.

For reference I googled a little bit trying to find an old comparison (the numbers are probably valid since HFS+ hasn't really changed much since their first iterations in OSX, other than adding Inline Attribute Data records, and access control list file security and maybe something else.

Here's the website with the charts:

Comparison Between HFS+ Journaled vs HFS+ Non-journaled

TL;DR:

The file copy/duplicate/copy sequence was pretty much equally fast for both journaled/non-journaled HFS. The same sequence with the folder was again somewhat faster with the journaled HFS

(emphasis mine)

Conclusion

I am somewhat surprised to see the above results, as I was kind of convinced that using Non-Journaled was really faster for some operations, but apparently the little cases where it can make a difference, it's overweighted by the "safety" of Journaling.

share|improve this answer
1  
+1 great answer –  conorgriffin Feb 2 '11 at 12:43
    
@Griffo actually it's +1 on the question for making me investigate and reach the above conclusion ;-) Thanks. –  Martín Marconcini Feb 2 '11 at 14:10
    
@MartínMarconcini the answer section "small overhead" lacks the overhead in terms of disk space consumption. For example, how much more disk space will be available for storing files when journaling is not enabled? –  Pro Backup Jul 5 '12 at 9:18
    
@ProBackup Although I don't have "numbers", I truly believe that the size of the Journal is going to be negligible in today's drives. –  Martín Marconcini Jul 5 '12 at 11:39
    
@MartínMarconcini I am wondering what the overhead in terms of consumed disk space is because: (1) Most of those bonus features are added proportionally. (2) All these extra they all add up: 209.7 MB for an EFI partition, another 1.4MB for the ability to create 128 partitions where only 1 is needed. (3) The fact diskutil moveJournal external will create a 512MB Apple_Journal partition. (4) On a 2.7TB (3TB old style) there is 736MB used (df -h) when storing only 1 file (according to sudo du /Volumes/Name). –  Pro Backup Jul 5 '12 at 17:12

Journaling adds delay and complexity to every operation that will get journaled. Journal writes force data to be written immediately to the drive which can make other outstanding drive transactions slower.

A nice treatment of what journaling does is in retired Technical Note TN1150: HFS Plus Volume Format.

The journal area on the file system is written heavily and forces the OS to hard sync data on a regular basis. This can interfere with large read and write operations that are happening at the same time as a file system modification that requires journal entries.

The advantage of a journaling system is that at mount time, the system can easily complete whatever file creation or directory modification entry that was in the middle of being attempted. The filesystem itself is repaired and made into a consistent state with extreme rapidity compared to a full file system catalog check.

For beginning users - having a computer ask them to repair a disk is not fun and provokes uncertainty and forces them to learn a bit about how things work. Yes - it brushes under the rug the fact that they could lose that one picture they were just downloading or moving. In practice, common sense ensures that even new users double checks the file before deleting it off the camera when the "darn computer" reboots in the middle of copying their photos to iPhoto. (More likely they call their support system for help at this point if they even notice the next boot was slower or it happens more than twice a week)

For advanced users that want the fastest performance, the benefits of journaling start to look more like penalties at the price of slower performance. These penalties can be substantial if the system is already near capacity or needs maximum performance for large sustained data transfers typical of pro video or some database workflows.

Things like these are good reasons to disable journaling:

  • database storage files
  • redundant machines with data healing routines after a failure
  • RAID storage that takes care of journaling and more
  • just needing extra speed no matter the cost
share|improve this answer
    
TN1150 seemed to disappear from the apple.com domain, then the 2004 edition reappeared as a retired document at developer.apple.com/legacy/mac/library/#technotes/tn/… then moved to developer.apple.com/legacy/library/technotes/tn/tn1150.html. There's a nostalgically styled copy of the 2004 edition at dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html –  Graham Perrin Aug 20 '13 at 2:12

You could have a look at the developer tools to compare disk performance of different filesystems if you were so inclined, there's a guide here: http://developer.apple.com/library/mac/DOCUMENTATION/Performance/Conceptual/FileSystem/Articles/MacOSXAndFiles.html

I can't find any comparison with hard numbers but it probably goes without saying that a journaling filesystem offers fault-tolerance but a non-journaling filesystem offers better performance

I added the file-system tag too

share|improve this answer
    
+1 for the dev link, I tend to forget how useful resource that is. And an invisible +1 for the retag ;-) –  koiyu Feb 2 '11 at 13:08

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.