|
When good UNIX File Systems go BAD
Earlier in 2002, when I was running a dual boot system and attempted to 'fix' a file system problem with a 'traditional' OS 9 disk type tool, the tool analyzed the disk and then informed me that it wanted to get rid of or change of 4000 folders and 32,000 files. That was just a BAD idea. I could pull some stuff of the affected disk and had recent full-disk back-ups, so that system ended up being rebuilt from scratch. (Actually as my 'play' system, it was been burned and rebuilt a few times in 2001.)
I had a positive experience with MicroMat's Drive 10 - at MWSF 2002, when I had a (battery) power-loss shutdown on my PBG3. Afterward, the 'bootable' OS X partition would not boot. Thirty-five hundred miles from home, at the start of a vacation with a digital camera and my PowerBook is paws-up. When I returned to my hotel room I plugged the machine into wall power and booted into OS X10.1 from my iPod. Then I fired up Drive 10, which worked overnight evaluating the 170,000 files on the disk - some 15 gigabytes of data. When complete - hours later - only one item was screwed up a needed to be fixed. I was happy with that.
From my experience with UNIX US file systems (and some with OS X's HFS+ file systems) when there is a power failure or system crash it is unusual to have a large number of files that need to be fixed. For UNIX File Systems there are three common types of problems after such an event:
- Bad Superblocks - usually detected by fsck, and restored from a copy
- Files - which were open and being written to, or writes were not completed
- Directories - which were being updated (due to file change operations)
Of these problems a damaged US directory can be the ugliest problem when it is something which affects system configuration or other needed system files - such as the '/etc' directory or another directory important to the system which experiences lots of write activity (e.g. the mail spool, log dir, etc.)
If certain files are open and being written when the system crashes, then all bets are off. In the normal course of things the system reads configuration files much more often then it writes to them. Individual mail spool files and logs files are often corrupted or perhaps a file you were editing, however this usually does not greatly impact the system.
Date Created: Jan. 22, 2002, updated October 2002 |
