It's just not possible to fairly evaluate filesystem performance
without first defining the application, its needs, and its environment.
As late as 1985, the V6 filesystem could still be found in Venix86 -
and the short code paths of this "obselete" and "primitive"
filesystem enabled Venix86 to handle 9600 baud on the
serial ports of an IBM XT, when "state of the art" Unix
systems on machines 10 times more expensive couldn't do so.
Software bloat is still a factor today -- judging by
a memo I saw recently that had been allegedly leaked
>From SGI - they may have some nasty problems here. All this goes
to show that "real time" almost as dangerous a word as "better".
In any event, the ``Scientific Computing'' business is certainly
a small part of the universe - for better or worse, MicroSoft Word
is a much more popular and important application.
In "V7" days, the "POSSIBLE FILESIZE ERROR" meant that there
were blocks in the file allocated past the "end" of the file.
That usually meant some data in the file got written out
before the inode was updated. I suppose it might have made
for anomalous behavior for an application that grew the file
and depended on the area between the old & new end of the
file being zero'd - but in practice that was never a problem.
As I recall, it usually happened for either temporary files,
or for pipes (remember when those used to be on disk?)
Oddly enough - I can't find this message in fsck for any of the systems
around here (netbsd, aix, sunos, ...) If recent versions of fsck
make this complaint for sparse files, I'd consider them at least
somewhat defective...
-Marcus Watts
UM ITD RS Umich Systems Group
