When booting a Unix™ or Unix-like computer after it has crashed, or you've had a power outage, you may see a message like this, and then you'll twiddle your fingers for a bit while the system takes longer than usual to give you a login: prompt. Depending on the size of your disks, you might even progress to foot tapping or table pounding. What's it all mean?

Let's talk about what a computer does with a disk drive, anyway. A disk holds one or more filesystems which contain … files! Now, you may have been told that your computer stores your family recipe for Coq au Vin here, and the letter you're writing to Aunt Millie there, and way over in the corner, last year's tax return. But it's not quite that simple. A disk drive will only read or write data in multiples of a particular size – the sector size, which is usually 512 bytes. Your computer's operating system will use one or more of these (possibly clumping them into small groups of 4 to 16 sectors, called disk blocks) to hold the content of the file; for example, your letter may be 12000 characters, and will be stored in 24 sectors. But those 24 sectors will not, in general, be all in the same place; the first 4 might be together, and the next 12 somewhere else, and the last 8 in yet a third place.

So, in addition to the actual data in the file, the system has to have a way to know how to find it all. The particulars of how a given filesystem does this are not important here; just realize that there are maps stored somehow that tell the filesystem which sectors – in which order – make up a particular file. And the disk sectors holding those maps might themselves be scattered all over the disk in an apparently haphazard manner. Those maps also keep track of all of the sectors that are not in use for any kind of data storage, so that when you save a new file, it knows where it can store it.

All of that, in itself, is not a problem. But there's one more kink: relative speeds. When I first started working with computers (in the mid '80s), a disk drive could do about thirty reads or writes per second. That seems fast — it's a heck of a lot faster than I can write. They're even faster now. The problem is, the microprocessor in a computer is much, much faster (and processors have been getting faster at a greater rate than disks have). They're so much faster, that when the system reads a block from the disk, it will do thousands and thousands of instructions worth of nothing while they wait for it to appear. (Not literally — the operating system will run another program if it can.)

The upshot of all of this is that, in order to avoid slowing the whole computer down by a few orders of magnitude, it is the case that many changes are made to the in-memory copies of your file data and the filesystem's mapping data, before the changes get written out to disk. And if the computer fails while all of that map data is out of date on the disk, before the filesystem can be put back into use again (after the system is restarted), the operating system must examine the disk and get all of its information back to an internally consistent state; if it went ahead and just made the filesystem available for use (called mounting it), it would eventually, and likely very quickly, get into a situation where the errors simply would not allow it to continue. Some user data is sometimes lost, but it is very unusual that the fsck program does not make the filesystem usable again.

When the filesystem is removed from service (unmounted), for example when the system is being properly shut down, all of the filesystem's data gets written to disk, and the last sector written contains an indication that the unmount occurred. Then, the following boot sees that and knows that the filesystem is in a good state. If instead, it sees that the mounted indicator is set, it knows that it cannot trust the condition and must repair it.

This situtation will occur less frequently in the future, as more and more systems use what is called a journaling filesystem; this is a filesystem that constantly logs the occurrence of vital filesystem modifications before they happen – which incurs a slight speed penalty, but much less than if all the data was actually written – and that can use that log information to repair the filesystem very quickly (usually less than five seconds) after a crash.

Log in or registerto write something here or to contact authors.