Marcus,
I think you missed understood my points. This discussion
started up over why sparse files did or did not work on SGI's version
of Unix(TM). I tried to explain a little history. I was trying to
give enough context to help folks understand what had happened.
I was >>not<< try to make System V or BSD look good or bad.
IMHO, UFS (aka BSD FF) is far ``better'' than the V7 family - and it
was ``silly'' that System V did not pick it up sooner. But that
was not the issue being debated.
All I was trying to imply is that many, many vendors can not
use >>either<< file system -- for two primary reasons in this case:
performance and predicability. Some other reasons to not use
either are: reliablity, fault tolerance, fast restart, etc...
I'm sure there are many more reasons that I have not listed.
As for Extent-Based File Systems, yes they have been
around for a very long time. As you point out, UCSD-P used them, as
did most of the Digital family (DOS-8, DOS-11, RT-11, RSTS, RSX-11*
VMS, TSS-8, TOPS, TENEX etc) [Some of us are, sadly, old enough to have
used all of those systems, sigh...] I'm fairly sure extent-based
file systems were used by Perkin_Elmer, DG, and probably IBM and
others too. They >>have<< been around for a very long time. And,
as you point, they are not an be-all-and-end-all. They have their
problems also. There are always design trade-offs everywhere --
that is, what we, as engineers get paid for...
On the on hand, when UNIX started being ``overhauled''
by folks in the ``Scientific Computing'' Business, its current
family of file systems did not work well (for different reasons).
The trade-offs made in the V7 and BSD family, were often not appropriate
This was not an issue of getting ``frustrated'' with the V7 file system.
If you take Masscomp alone, a quadratic block search (like BSD FF
has in it) will not do in a ``real-time'' system. Similarly,
for Stellar and I would expect SGI, when N-way striping files for
very fast FORTRAN I/O, you need to ``know'' where the blocks are.
While the BSD FF file system is ``better'' -- it is just not cool for
those uses.
On the other hand, some of the extent-based tricks cause a few
nuisances for general time-sharing (like disk compression). In fact
to pick on Masscomp, we never wrote our own ``compact file system''
program [eventually somebody, David Arnovitz, did and put it in their
user group library].
Similarly, as UNIX went into the ``Commerial'' business,
the file systems were again overhauled -- TTS (now called Veritas)
built a ``log structured file system for their UNIX. As you point
out, IBM built JFS. Digital built its AdvFS. BSD built one also.
>>>And there have been many others in non-UNIX systems. I'm not
trying to be complete... just trying to explain how we got here!!<<<
As for the whole issue of what got Info-AFS here... sparse
files -- you are right few programs use them. But they are used.
Look at your fsck messages. The ``POSSIBLE FILE SIZE ERROR''
message [note to tjk - man if we could change one message in our
past lives....]. This is fsck telling us that it found a sparse
file. On my file server I tend to get 5-10 of them on my root.
Now there >>was<< an argument for them, which when UNIX
was young, did hold water. In the old days of >>Version 5<<, you
know before Honeyman... ;-) RK05 disks had 4820 blocks -- yes folks
2.4 megs. That was your root file systems and you had another for
/usr (none of the /home stuff). In those days, RK05 >>drives<<cost
about $6k-8K and the disk packs (single platter) cost a few hundred
(cost per meg is left as an exercise...) Making the file sparse could
just save you a block or two and that was always cost effective.
However.... in the days of storage that cost 1/Megabyte, saving
a few blocks on the disk may not be worth it. Certainly, trading
the storage savings vs the predicable behavior in RT systems - it's
not worth it
So.... to close......
Not all UNIX ``physical'' file systems have sparse files.
There is no requirment (POSIX or the like) for them. Thus ``layered''
file systems like AFS, Ficus or CFE, will ``inherit'' the storage
behavior of the physical filesystem (BSD FF, EFS, Veritas etc)..
Now lets get this discussion back to AFS issues....
Clem
