a journaling file system
Think of a careful accountant who, before changing the main ledger, first jots the whole intended change on a notepad: deduct 50 from account A, add 50 to account B. If she is interrupted halfway through editing the ledger, she can return to the notepad and either finish the change or, if the note is incomplete, discard it. The notepad guarantees the ledger never ends up half-changed. A journaling file system keeps exactly such a notepad — the journal (or log) — to survive crashes.
The technique is called write-ahead logging. Before touching the real file-system structures, the file system first writes a record of the entire intended update into a dedicated journal area on the disk, and waits for that write to land. This record (a transaction) says, in effect, here are all the metadata changes for creating note.txt: bitmap block changes, inode contents, directory entry. Only after the journal record is safely committed does the file system go on to update the real locations on disk. When everything is done, the journal entry is marked complete and can be reused. The payoff comes after a crash: instead of scanning the whole disk, the system reads only the journal. Any transaction that was fully committed to the journal but not yet finished on disk is simply replayed (redone) to completion; any that was not fully committed is discarded. Recovery takes seconds, not the minutes or hours of a full fsck.
Journaling is the default in ext3, ext4, NTFS, and many others, and it is the standard answer to crash consistency. Two honest points: writing every change twice (once to the journal, once to the real location) costs performance, so most systems journal only metadata by default, not file data — which is why a crash can leave a metadata-consistent file system whose newest file contents are still garbage or zeros. And the journal protects only what was written to it; data still sitting in the volatile buffer cache, never logged, is gone in a crash regardless.
ext4 (in its default ordered mode) creating a file: it writes a journal transaction describing the inode, bitmap, and directory changes and commits it; then it writes those changes to their real spots. If the power dies mid-update, on reboot the kernel replays the committed journal transaction and the file appears correctly — no full disk scan needed.
Write the plan to the journal first, then do it; on crash, replay committed plans and discard the rest.
By default journaling protects metadata, not your file data — a crash can yield a perfectly consistent file system whose just-created file is full of zeros. Logging data too (full data journaling) is safer but slower.