UFS: The Root of All Evil 269 Good luck. We spoke with the current system administrator at the MIT AI Lab about this problem. He told us: Date: Mon, 4 Oct 93 07:27:33 EDT From: bruce@ai.mit.edu (Bruce Walton) Subject: UNIX-HATERS To: simsong@next.cambridge.ma.us (Simson L. Garfinkel) Hi Simson, I recall the episode well I was a lab neophyte at the time. In fact it did happen more than once. (I would rather forget!:-) ) Life would barf file system errors and panic, and upon reboot the mail partition was hopelessly scrambled. We did write some scripts to grovel the To: addresses and try to assign uids to the files. It was pretty ugly, though, because nobody could trust that they were getting all their mail. The problem vanished when we purchased some more reliable disk hardware… No File Types To UFS and all Unix-derived file systems, files are nothing more than long sequences of bytes. (A bag’o’bytes, as the mythology goes, even though they are technically not bags, but streams). Programs are free to interpret those bytes however they wish. To make this easier, Unix doesn’t store type information with each file. Instead, Unix forces the user to encode this information in the file’s name! Files ending with a “.c” are C source files, files ending with a “.o” are object files, and so forth. This makes it easy to burn your fingers when renaming files. To resolve this problem, some Unix files have “magic numbers” that are contained in the file’s first few bytes. Only some files—shell scripts, “.o” files and executable programs—have magic numbers. What happens when a file’s “type” (as indicated by its extension) and its magic number don’t agree? That depends on the particular program you happen to be running. The loader will just complain and exit. The exec() family of kernel func- tions, on the other hand, might try starting up a copy of /bin/sh and giving your file to that shell as input. The lack of file types has become so enshrined in Unix mythology and aca- demic computer science in general that few people can imagine why they
270 The File System might be useful. Few people, that is, except for Macintosh users, who have known and enjoyed file types since 1984. No Record Lengths Despite the number of databases stored on Unix systems, the Unix file sys- tem, by design, has no provision for storing a record length with a file. Again, storing and maintaining record lengths is left to the programmer. What if you get it wrong? Again, this depends on the program that you're using. Some programs will notice the difference. Most won’t. This means that you can have one program that stores a file with 100-byte records, and you can read it back with a program that expects 200-byte records, and won’t know the difference. Maybe… All of Unix’s own internal databases—the password file, the group file, the mail aliases file—are stored as text files. Typically, these files must be pro- cessed from beginning to end whenever they are accessed. “Records” become lines that are terminated with line-feed characters. Although this method is adequate when each database typically had less than 20 or 30 lines, when Unix moved out into the “real world” people started trying to put hundreds or thousands of entries into these files. The result? Instant bottleneck trying to read system databases. We’re talking real slowdown here. Doubling the number of users halves performance. A real system wouldn’t be bothered by the addition of new users. No less than four mutu- ally incompatiable workarounds have now been developed to cache the information in /etc/password, /etc/group, and other critical databases. All have their failings. This is why you need a fast computer to run Unix. File and Record Locking “Record locking” is not a way to keep the IRS away from your financial records, but a technique for keeping them away during the moments that you are cooking them. The IRS is only allowed to see clean snapshots, lest they figure out what you are really up to. Computers are like this, too. Two or more users want access to the same records, but each wants private access while the others are kept at bay. Although Unix lacks direct record support, it does have provisions for record locking. Indeed, many people are surprised that modern Unix has not one, not two, but three completely different systems for record locking. In the early days, Unix didn’t have any record locking at all. Locking vio- lated the “live free and die” spirit of this conceptionally clean operating system. Ritchie thought that record locking wasn't something that an oper- ating system should enforce—it was up to user programs. So when Unix
Previous Page Next Page