UFS: The Root of All Evil 273 Only the Most Perfect Disk Pack Need Apply One common problem with Unix is perfection: while offering none of its own, the operating system demands perfection from the hardware upon which it runs. That’s because Unix programs usually don’t check for hard- ware errors—they just blindly stumble along when things begin to fail, until they trip and panic. (Few people see this behavior nowadays, though, becuase most SCSI hard disks do know how to detect and map out blocks as the blocks begin to fail.) The dictionary defines panic as “a sudden overpowering fright especially a sudden unreasoning terror often accompanied by mass flight.” That’s a pretty good description of a Unix panic: the computer prints the word “panic” on the system console and halts, trashing your file system in the process. We’ve put a list of some of the more informative(?) ones in Figure 4. The requirement for a perfect disk pack is most plainly evident in the last two of these panic messages. In both of these cases, UFS reads a block of data from the disk, performs an operation on it (such as decreasing a num- Message Meaning panic: fsfull The file system is full (a write failed), but Unix doesn’t know why. panic: fssleep fssleep() was called for no apparent rea- son. panic: alloccgblk: cyl groups corrupted Unix couldn’t determine the requested disk cylinder from the block number. panic: DIRBLKSIZ fsize A directory file is smaller than the mini- mum directory size, or something like that. dev = 0xXX, block = NN, fs = ufs panic: free_block: freeing free block Unix tried to free a block that was already on the free list. (You would be surprised how often this happens. Then again, maybe you wouldn’t.) panic: direnter: target directory link count Unix accidentally lowered the link count on a directory to zero or a negative num- ber. FIGURE 4. Unix File System Error Messages.

274 The File System ber stored in a structure), and obtains a nonsensical value. What to do? Unix could abort the operation (returning an error to the user). Unix could declare the device “bad” and unmount it. Unix could even try to “fix” the value (such as doing something that makes sense). Unix takes the fourth, easiest way out: it gives up the ghost and forces you to put things back together later. (After all, what are sysadmins paid for, anyway?) In recent years, the Unix file system has appeared slightly more tolerant of disk woes simply because modern disk drives contain controllers that present the illusion of a perfect hard disk. (Indeed, when a modern SCSI hard disk controller detects a block going bad, it copies the data to another block elsewhere on the disk and then rewrites a mapping table. Unix never knows what happened.) But, as Seymour Cray used to say, “You can’t fake what you don’t have.” Sooner or later, the disk goes bad, and then the beauty of UFS shows through. Don’t Touch That Slash! UFS allows any character in a filename except for the slash (/) and the ASCII NUL character. (Some versions of Unix allow ASCII characters with the high-bit, bit 8, set. Others don’t.) This feature is great—especially in versions of Unix based on Berkeley’s Fast File System, which allows filenames longer than 14 characters. It means that you are free to construct informative, easy-to-understand filena- mes like these: 1992 Sales Report Personnel File: Verne, Jules rt005mfkbgkw0.cp Unfortunately, the rest of Unix isn’t as tolerant. Of the filenames shown above, only rt005mfkbgkw0.cp will work with the majority of Unix utili- ties (which generally can’t tolerate spaces in filenames). However, don’t fret: Unix will let you construct filenames that have control characters or graphics symbols in them. (Some versions will even let you build files that have no name at all.) This can be a great security feature— especially if you have control keys on your keyboard that other people don’t have on theirs. That’s right: you can literally create files with names that other people can’t access. It sort of makes up for the lack of serious security access controls in the rest of Unix.