[Epic 4G Q&A, Help & Troubleshooting] mkasick:
It's already been posted, but journaling is a feature of journaling file systems.

Most operations performed by a file system consist of multiple fundamental "steps". Should the file system stop running (i.e., a bug causes the kernel to panic or the computer/phone loses power) before all the steps for a given operation completes, then the file system is left in an inconsistent state.

Consider the example of moving a file from one directory to another. In simplified terms, this consists of two steps: (i) copying the file to the destination directory, and (ii) deleting the file from the source directory. Now, suppose the phone crashes after copying the file (step i) but before deleting it (step ii). When the phone boots again, the file exists in both directories when it should only exist in one. That's the basic idea of file system inconsistency. Although that particular scenario is relatively harmless, there's more complicated situations in which a phone crash can result in deleted-but-not-freed data, half-written files, and all sorts of other inconsistencies.

Now, journaling file systems are different in that they maintain a transaction log (a journal) where the fundamental steps for operations are recorded before they are carried out. In the event of a crash, the file system replays the jounal on reboot and performs any outstanding operation that has been committed to the journal.

In the above example, a journaling file system would: (i) record in the journal that it is copying & deleting the file, (ii) commit the journal, then actually (iii) copy the file to the destionation directory, and (iv) delete the file from the source. In the event of a crash, the operation either has been committed to the journal, in which case it's verified that the subsequent steps were performed and are performed if not, or the operation hasn't been committed yet, in which case no changes have been made. This guarantees that, following a journal replay, the file system is always in a consistent state.

Now, it's true that maintaining a journal carries some performance penalty as operations have to be written to the file system twice. Modern file systems, like ext4, get around this by delaying the non-journal write operations until a later time when the file system is (relatively) idle. So the actual decrease in performance is minimal if any. This also means that running these file systems with journaling disabled is potentailly more dangerous than non-journaled file systems as operations may remain outstanding for far longer than they would otherwise, increasing their succeptability to loss in the event of a crash.

It's also worth noting that the primary purpose of file system journaling is to gurarantee file system consistency, not avoid data corruption. Most journaled file system only journal metadata, that is, only the operations carried out on a file are journaled, not the actual data content. This is why a battery pull is always a bad idea and should be avoided unless absolutely necessary.

Still, in the worst case, a journaling file system after reboot will only suffer data corruption in the files most recently modified before a crash, whereas a non-journaled file system may suffer corruption of the underlying file system structure, possibly rendering many non-recently modified files inaccessible. In other words, with a journaled file system, in the worst case you might have to "Clear data" on one or two apps to recover, whereas with a non-journaled one the entire file system might be hosed.

Just to note: journaling is irrelevant with regard to data corruption on an application-level crash. Any outstanding changes made by the application to the file system are still performed by the kernel, even after the application itself crashes.

Journaling protects in situation where the kernel itself is unable to complete any outstanding changes due to crash (kernel panic) or powerloss.