fsck stands for F
, and is a Unix disk repair utility. To use it, boot your computer into single-user mode (hold down command-s after the startup chime). At the command prompt, type "fsck -fy". If when it has finished, you see the message "File System has been modified" run fsck -y again, and continue to do so until you no longer see the "File System has been modified" message. Once you are done, type "reboot". fsck can't fix everything, but it is a handy utility. For the record, Apple prefers that you use the Disk Utility program to fix possible problems. To use it, boot the computer with your OS X install CD and select Open Disk Utility from the menu.
Update: Apple has finally posted an article on fsck and related issues - ?find it here.Note:
With 10.3 (Panther) Apple has introduced journaling to OS X (Client anyway, Server has had it since 10.2) and made it the default. This has had the effect of making fsck largely superfluous, except in situations where for whatever reason you can't run Disk Utility. To explain a bit about why this is, I will quote an excellent post by iMeowbot
Basically, journaling is a way to make all the crazy things an operating system has to do in order to accomplish a disk write (update allocation lists, chains of blocks, directory entries, etc.) closer to atomic. It's not _really_ atomic if you peek under the covers, since metadata-only journaling still writes the data itself in a separate step, but it's way lots closer. After the journal entry is written, the filesystem goes back later and fills the information into the traditional spots (this is the part where people assume it must be slow), but at this point it's redundant so it can be cached/deferred (so it can be done in the background and isn't quite so slow after all -- more on that in a bit).
Anyway, the net effect of all this is that the kinds of problems that fsck is intended to fix rarely get a chance to happen in the first place. That's why it's enabled by default. It's also a big part of why Panther tends to boot more quickly: fsck is a part of the normal boot process if a volume appears to be "dirty" (i.e., potentially incomplete writes) and there isn't a journal to verify the state.
Journals won't really slow things down appreciably unless you have some program with pathological tendencies to write lots and lots and lots of little files all over the place all the time. Unless you're running some sort of high-traffic database-like server software, you aren't really doing that (and if you _are_ doing that, you probably would prefer a little write performance hit over losing all those transactions -- those are the same applications where RAID 5 gets used, after all.).
So: leave the journaling on unless you have actual performance problems (and I mean actual problems, rather than hopes of squeezing a few milliseconds out of saving a file) that need to be addressed. And, if you're got journalling on. don't bother fscking around unless you have an actual problem to fix -- the OS is already working hard to keep that stuff from happening.
last modified: 2004-08-29 19:27:56