278 The File System Weird, huh? It’s sort of like someone who sets his watch five minutes ahead and then arrives five minutes late to all of his appointments, because he knows that his watch is running fast. Don’t Forget to write(2) Most Unix utilities don’t check the result code from the write(2) system call—they just assume that there is enough space left on the device and keep blindly writing. The assumption is that, if a file could be opened, then all of the bytes it contains can be written. Lenny Foner explains it like this: Date: Mon, 13 Nov 89 23:20:51 EST From: foner@ai.mit.edu (Leonard N. Foner) To: UNIX-HATERS Subject: Geez… I just love how an operating system that is really a thinly disguised veneer over a file system can’t quite manage to keep even its file sys- tem substrate functioning. I’m particularly enthralled with the idea that, as the file system gets fuller, it trashes more and more data. I guess this is kinda like “soft clipping” in an audio amplifier: rather than have the amount of useful data you can store suddenly hit a wall, it just slowly gets harder and harder to store anything at all… I’ve seen about 10 messages from people on a variety of Suns today, all complaining about massive file system lossage. This must be closely related to why ‘mv’ and other things right now are trying to read shell commands out of files instead of actually moving the files themselves, and why the shell commands coming out of the files correspond to data that used to be in other files but aren’t actually in the files that ‘mv’ is touching anyway… Performance So why bother with all this? Unix weenies have a single answer to this question: performance. They wish to believe that the Unix file system is just about the fastest, highest-performance file system that’s ever been written. Sadly, they’re wrong. Whether you are running the original UFS or the new and improved FFS, the Unix file system has a number of design flaws that prevent it from ever achieving high performance.
UFS: The Root of All Evil 279 Unfortunately, the whole underlying design of the Unix file system—direc- tories that are virtually content free, inodes that lack filenames, and files with their contents spread across the horizion—places an ultimate limit on how efficient any POSIX-compliant file system can ever be. Researchers experimenting with Sprite and other file systems report performance that is 50% to 80% faster than UFS, FFS, or any other file system that implements the Unix standard. Because these file systems don’t, they’ll likely stay in the research lab. Date: Tue, 7 May 1991 10:22:23 PDT From: Stanley’s Tool Works lanning@parc.xerox.com Subject: How do you spell “efficient?” To: UNIX-HATERS Consider that Unix was built on the idea of processing files. Consider that Unix weenies spend an inordinate amount of time micro-opti- mizing code. Consider how they rant and rave at the mere mention of inefficient tools like a garbage collector. Then consider this, from an announcement of a recent talk here: …We have implemented a prototype log-structured file system called Sprite LFS it outperforms current Unix file systems by an order of magnitude for small-file writes while matching or exceeding Unix performance for reads and large writes. Even when the overhead for cleaning is included, Sprite LFS can use 70% of the disk bandwidth for writing, whereas Unix file systems typically can use only 5-10%. —smL So why do people believe that the Unix file system is high performance? Because Berkeley named their file system “The Fast File System.” Well, it was faster than the original file system that Thompson and Ritchie had written.
Previous Page Next Page