272 The File System AT&T, meanwhile, was trying to sell Unix into the corporate market, where record locking was required. It came up with the idea of mandatory record locking. So far, so good—until SVR4, when Sun and AT&T had to merge the two different approaches into a single, bloated kernel. Date: Thu, 17 May 90 22:07:20 PDT From: Michael Tiemann cygint!tiemann@labrea.stanford.edu To: UNIX-HATERS Subject: New Unix brain damage discovered I’m sitting next to yet another victim of Unix. We have been friends for years, and many are the flames we have shared about The World’s Worst Operating System (Unix, for you Unix weenies). One of his favorite hating points was the [alleged] lack of file locking. He was always going on about how under real operating systems (ITS and MULTICS among others), one never had to worry about losing mail, losing files, needing to run fsck on every reboot… the minor inconveniences Unix weenies suffer with the zeal of monks engaging in mutual flagellation. For reasons I’d rather not mention, he is trying to fix some code that runs under Unix (who would notice?). Years of nitrous and the Grateful Dead seemed to have little effect on his mind compared with the shock of finding that Unix does not lack locks. Instead of having no locking mechanism, IT HAS TWO!! Of course, both are so unrelated that they know nothing of the other’s existence. But the piece de resistance is that a THIRD system call is needed to tell which of the two locking mechanisms (or both!) are in effect. Michael This doesn’t mean, of course, that you won’t find lock files on your Unix system today. Dependence on lock files is built into many modern Unix utilities, such as the current implementation of UUCP and cu. Furthermore, lock files have such a strong history with Unix that many programmers today are using them, unaware of their problems.

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.