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
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