Not to confuse matters even more, but it's somewhat
of an oversimplification to say "V7 / BSD / UFS"
filesystem and to condemn their performance in
two sentences.
The stock V7 filesystem used 512 byte blocks and
a linked freelist. It survived little changed at least
into system V release 3, the most distinct change being
the use of larger blocks (probably 1K, although this
varied some between implementations. The V7 filesystem
could still be found in even "recent products" such as AIX/370.
The V7 filesystem had a number of well-known problems,
including:
allocation performance that got worse with time
(as the free list got more randomized)
trade-off between larger file performance (larger blocks)
and disk utilization (smaller blocks).
(Studies show that with typical computing
applcations, most files are in fact "small"...<4K.)
"unpopular" behavior on crashes.
later versions (esp. S5) made efforts to do
things in the "right order".
That's why almost everyone has decided to "improve" it.
The Berkeley fast filesystem, first introduced in 4.2bsd,
added the following changes:
bitmap allocation
cylinder groups
block fragmentation
bitmap allocation & cylinder groups get rid of most of the
"randomized" free list trouble. Block fragmentation makes
large files perform better while still making efficient use
of disk space (compare this with recent versions of MS-DOS.)
The berkeley filesystem is probably the closest thing there
is to a "standard" today and can be found in most versions
of SunOS, etc. It went into system V quite recently, as of
release 4, and it can be found in AIX/ESA.
Because the system V world "found" the berkeley fast file
system "later", they've had more time to get frustrated
with the stock system V filesystem, and evolve variations.
For instance, there is the RS/6K version of AIX, "jfs". It seems
to have bitmap allocation & cylinder groups - so obviously they've
done their homework. It doesn't seem to have block fragmentation.
(Of course, since IBM is in the disk drive business, that's not too
surprising.) One of the "neat" things about "jfs" is that it logs
filesystem changes, so that disk recovery after most crashes can be
done simply by replaying the log. Another "neat" future of
"jfs" is the ability to grow the filesystem on the disk without
dismounting the partition and copying all the data to tape &
back - a major drag.
Contiguous files have been around for a long time - in fact, that's
the only sort of file the UCSCD P-code system supported. Contiguous
files generally require you know how big your data is in advance, and
don't generally make good use of disk space (it was necessary to
"compact" one's P-code disk every so often). That makes them
ill suited for "general purpose" needs, despite their "superior"
performance.
So far as "sparse files" goes, it's not really much of
a surprise AFS doesn't do a very good job with them.
It's really quite simple: the most popular use of "sparse files"
is with database packages such as "dbm". One might want to
use such a database from either a single machine, or from
multiple machines. The single-machine case will obviously
benefit from storing it on the local disk. If use of the
database involves any amount of writing, it's necessary to do
locking, and there are all sorts of bad things about network
locks - which means they perform, at best, not nearly as well
as locks based purely on the local machine. Only in the case
where the database changes rarely does it make sense to store
a file out on the network, in which case, it's often simplier to
write out a "packed" database. Simply by looking at how files are
used in Unix, it's easy to conclude that sparse files should be a
pretty low priority in any network filesystem, so it's not much of
a surprise they just don't work right in AFS.
-Marcus Watts
UM ITD RS Umich Systems Group
