I am asking this question on behalf of another user who raised the issue in the Ubuntu chat room.

Do journaling filesystems guarantee that no corruption will occur if a power failure occurs?

If this answer depends on the filesystem, please indicate which ones do protect against corruption and which ones don't.

6 Answers 6


There are no guarantees. A Journaling File System is more resilient and is less prone to corruption, but not immune.

All a journal is is a list of operations which have recently been done to the file system. The crucial part is that the journal entry is made before the operations take place. Most operations have multiple steps. Deleting a file, for example might entail deleting the file's entry in the file system's table of contents and then marking the sectors on the drive as free. If something happens between the two steps, a journaled file system can tell immediately and perform the necessary clean up to keep everything consistent. This is not the case with a non-journaled file system which has to look at the entire contents of the volume to find errors.

While this journaling is much less prone to corruption than not journaling, corruption can still occur. For example, if the hard drive is mechanically malfunctioning or if writes to the journal itself are failing or interrupted.

The basic premise of journaling is that writing a journal entry is much quicker, usually, than the actual transaction it describes will be. So, the period between the OS ordering a (journal) write and the hard drive fulfilling it is much shorter than for a normal write: a narrower window for things to go wrong in, but there's still a window.

Further reading from archived IBM pages:

  • Could you please elaborate a little bit on why this is true? Perhaps you could give an example of how corruption would occur in a certain scenario. May 6, 2011 at 2:57
  • 1
    @George Edison See my expanded answer. May 6, 2011 at 3:21
  • 4
    That last bit is incorrect; there is no window for things to go wrong. Since it records what it is about to do before it starts doing it, the operation can be restarted after the power failure, no matter at what point it occurs during the operation. It is a matter of ordering, not timing.
    – psusi
    May 6, 2011 at 17:58
  • 1
    @psusi there is still a window for the write to the journal to be interrupted. Journal writes may appear atomic to the OS but they're still writes to the disk. May 6, 2011 at 21:23
  • 11
    @Amazed they are atomic because they have sequence numbers and/or checksums, so the journal entry is either written entirely, or not. If it is not written entirely, it is simply ignored after the system restarts, and no further changes were made to the fs so it remains consistent.
    – psusi
    May 7, 2011 at 1:57


The most common type of journaling, called metadata journaling, only protects the integrity of the file system, not of data. This includes xfs, and ext3/ext4 in the default data=ordered mode.

If a non-journaling file system suffers a crash, it will be checked using fsck on the next boot. fsck scans every inode on the file system, looking for blocks that are marked as used but are not reachable (i.e. have no file name), and marks those blocks as unused. Doing this takes a long time.

With a metadata journaling file system, instead of doing an fsck, it knows which blocks it was in the middle of changing, so it can mark them as free without searching the whole partition for them.

There is a less common type of journaling, called data journaling, which is what ext3 does if you mount it with the data=journal option.

It attempts to protect all your data by writing not just a list of logical operations, but also the entire contents of each write to the journal. But because it's writing your data twice, it can be much slower.

As others have pointed out, even this is not a guarantee, because the hard drive might have told the operating system it had stored the data, when it fact it was still in the hard drive's cache.

For more information, take a look at the Wikipedia Journaling File System article and the Data Mode section of the ext4 documentation.

  • 1
    +1 for the distinction between file system corruption and data corruption. That little distinction is quite the doozy in practice. May 6, 2011 at 8:03
  • 1
    Again, the OS knows when the drive caches data and forces it to flush it when needed in order to maintain a coherent fs. Your data file of course, can be lost or corrupted if the application that was writing it when the power failed was not doing so carefully, and that applies whether or not you use data=journal.
    – psusi
    May 6, 2011 at 18:11
  • 1
    @user3338098, drives that silently corrupt data are horribly broken and should not ever be used, and are an entirely different conversation than corruption caused by software doing the wrong thing.
    – psusi
    Aug 21, 2016 at 3:22
  • 1
    @user3338098, drives may fail in old age, but they are never, ever, ever supposed to silently corrupt data. The only time I have ever seen a drive do that was with an OCZ SSD and as a result I will never trust OCZ with my data again.
    – psusi
    Oct 7, 2016 at 17:46
  • 1
    @psusi It seems that the way things are supposed to be are rarely the way things actually are. en.wikipedia.org/wiki/Data_corruption#SILENT As another example, a real-life study performed by NetApp on more than 1.5 million HDDs over 41 months found more than 400,000 silent data corruptions, out of which more than 30,000 were not detected by the hardware RAID controller. Another study, performed by CERN over six months and involving about 97 petabytes of data, found that about 128 megabytes of data became permanently corrupted. Mar 7, 2017 at 20:06

A filesystem cannot guarantee the consistency of its filesystem if a power failure occurs, because it does not know what the hardware will do.

If a hard drive buffers data for write but tells the OS that it has written the data and does not support the appropriate write barriers, then out-of-order writes can occur where an earlier write has not hit the platter, but a later one has. See this serverfault answer for more details.

Also, the position of the head on a magnetic HDD is controlled with electro-magnets. If power fails in the middle of a write, it is possible for some data to continue to be written while the heads move, corrupting data on blocks that the filesystem never intended to be written.

  • Isn't the drive's firmware smart enough to suspend writing when retracting the head? May 6, 2011 at 6:43
  • @George: It's going to depend on the drive. There's a lot out there and you don't know how well your (cheap) drive does things.
    – camh
    May 6, 2011 at 7:54
  • 3
    The hard drive tells the OS if it uses a write behind cache, and the OS takes measures to ensure they are flushed in the correct order. Also drives are designed so that when the power fails, they stop writing. I have seen some cases where the sector being written at the time of power loss becomes corrupt because it did not finish updating the ecc ( but can be easily re-written correctly ), but never heard of random sectors being corrupted on power loss.
    – psusi
    May 6, 2011 at 18:05

ZFS, which is close but not exactly a journaling filesystem, is guaranteeing by design against corruption after a power failure.

It doesn't matter if an ongoing write is interrupted in the middle as in such case, its checksum will be certainly incorrect so the block will be ignored. As the file system is copy on write, the previous correct data (or meta-data) is still on disk and will be used instead.


The answer is in most cases no:

  • As already mikel said, most journaling file systems can only protect file metadata (information like the name of a file, its size, its permissions, etc.), not file data (the file's contents). This is happening because protecting file data results in a very slow (in practice useless) file system.
  • Since the journal is also a special kind of file stored on the hard disk, it can be damaged after a power failure. Thus if the journal is corrupted the file system cannot complete any incomplete transactions that were taking place when the power failure occured.
  • What events could lead to a corrupt journal? The only thing I could think of was bad sectors - is there anything else? May 6, 2011 at 16:35
  • That's right, hardware failures are the usual case.
    – sakisk
    May 7, 2011 at 13:21

The other answers have impressive arguments that the file system cannot guarantee against corruption after a power failure, but my observation is that these are just theories, and are contradicted by the practice that nowadays a power failure does NOT cause corruption.

I worked with the earliest Personal Computers and yes, in the old days, a power failure was dangerous for your data. The Microsoft DOS solution was to not cache disk writes. Slow, but reliable. A power failure of course caused the loss of the unsaved part of your work, but the machine could usually be started again. Usually, but not always. I have often had to start up in Windows Safe Mode, or by going through lengthy Linux file system check (fsck) sessions. Up to, let's say, the year 2010 ?

Today, with journaling file systems, like linux ext3/4 and Windows NTFS, disk caching can withstand power failures. Where it still goes wrong is with Raspberry Pi with a file system on an SD Card. Other than that I do not see problems with power failures.

And I have seen a LOT of power failures. Simple ones: if the machine is frozen, you may have to press the power button up to 10 seconds for power shutdown by the BIOS, or even to literally "pull the plug". Even today. Because the OS, or misbehaving app, can still freeze the machine. In recent months I several times had to remove the laptop battery. Or remove the phone (FairPhone) battery. And this were modern, expensive machines, not old crap.

At work I have seen the power go down for one room, or the entire floor, building or city, stopping LOTS of machines, that all just started up normally when power was restored. Sure, an occasional machine may have hardware damage from the power failure, but apparently the journaling file system protection worked.

By the way, because I started in electrical engineering, power failures are now much more a part of life. Starting with the liberalization in the 1980's, the focus of the energy companies changed from "the lights will not go out", with redundant power infrastructure and sufficient maintenance, to profitability, cost-cutting, marketing, and the invention of the Service Level Agreement SLA, basically saying that the reliability of the power supply is a contractually defined percentage below 100, and power companies also offering backup power "solutions" for a price.

A backup power supply, PSU, is recommended, but I have seen those only in the server rooms. Those PSU's served to avoid loss of service, not disk failures.

A couple of years ago started the BIOS option to enable/disable automatic startup when external power is turned on, or to apply a random waiting time delay. This is to avoid tripping the main circuit breaker for a room or floor when a dozen PC's start up simultaneous when power is restored, and where each PC causes a high "inrush current" peak at startup. Today, power supplies also do not have a high inrush current anymore. This are measures that are needed in a time where literally everybody is working on a PC. Before, say, the year 2000, a much smaller percentage of workers had a PC. Anyway, my point is that all those current PC's got improvements for the problem of starting up, but do not have a real problem with unexpected power failures, thanks to journaling file systems.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .