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: [email protected] (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.