Mail Archives: opendos/1998/02/03/16:52:15
> Sad but true, the issue is compatibility moreso than function. I can't
> wait for FAT32 in DOS and NT and LINUX so I can have efficient use of my
> disks and shared data at the same time - sigh...
I'm not sure if MS mean to continue with FAT32. In any case it is a
poorly designed, inefficient system. But, as you say: compatibility is
what people want.
The non-FAT file system that is available read-write under the most
operating systems seems to be HPFS (from OS/2; it works under NT, and
shareware read-write versions are available for DOS, but readonly for
Linux). Next is ext2fs from Linux (readonly though for everything
except Linux and OS/2, as far as I know).
There are some commercial file systems (the VFS from Veritas comes to
mind) that can be bought for quite a few operating systems, but
something like ext2fs is likely to have the best hopes for porting (out
of the present choices) because the code is easily obtainable and it is
a good enough design to make it *worth* porting. FAT32 keeps a
dreadfully large File Alllocation Table. And the very fact that you
have to go via a FAT for reads is inefficient on low-end systems and
high-end systems alike (the former because you aren't likely to have it
all in RAM, the latter because the FAT is at the start of the disk,
meaning you have to move the heads too much each fs update).
NTFS is surprisingly wasteful, but still turns out prety fast on
high-end computers (not much good for low-end). In fact most of the
good filesystems have high overheads when implementing drivers
(especially if not read-only) on moderate sized systems, and DOS in
particular.
All FAT-like file systems are derived from the CP/M idea with the
change that the list of sectors isn't stored in the directory entries.
That change made sense at first glance, but wasn't really a good
design, even but 1980 standards. Good file system design was already
available for small computers in the 1970's, for example: Data
General's RDOS (much, much more efficient then DEC's equivalents, or
FAT).
The funny thing is that RDOS ran in 64Kb of RAM (in fact the O/S took
about 20Kb), so it isn't some big, complicated arrangement. At its
heart, there were two design features that *should* have been
introduced into DOS some time. One is that the directory, SYS.DR, had
hash-encoding - if you knew the filename you could probably get the
directory entry with one disk read. The second was that the way the
system knows where the sectors of a file reside on disk could come from
3 methods - you could choose which method you thought best for the
particular file (else the system would choose for you). One was
"contiguous", where the directory entry only needed to store the start
location and length, and each sector followed straight on. This is
very efficient for speed, but a nuisance for expansion of the file.
Another was "sequential", where a few bytes at the end of each sector
told the system where the next sector resides (less disk movement going
to the FAT all the time, but bad for random access), and the last (the
best all-round system) was to store a block of sector addresses for
ecah file (a long file would have several index blocks). At first
sight having index blocks per file may seem a waste of space, but
compared with the FAT system (where you often allocate clusters of
several Kb) there are no extra blocks wasted at the end of files.
I don't think there is any problem introducing a new file system to the
world - so long as somebody eventually ports it to a good number of
operating systems there is no stigma associated with running a
"non-standard" file system, as there sometimes is with running a
different word procesor or operating system. You can go ahead and make
a technically-good system, and don't have to fear Bill will put the
pressure on to isolate it.
So do I have any volunteers to help? I'd like to simultaneously
develope OpenDOS, Linux and OS/2 versions. Although I can develop for
all of these I don't have the time to do all the work myself.
Email me if you are interested!
---------------------------------------------------------------------------
Mark Aitchison, \_ Phone: +64 3 364-2947 home 337-1225
Dept of Physics & Astronomy, </ Fax: +64 3 364-2469 or 364-2999
University of Canterbury, /) Web: www.phys.canterbury.ac.nz/~physmsa
Christchurch, NEW ZEALAND. (/' E-mail: M DOT Aitchison AT phys DOT canterbury DOT ac DOT nz
---------------------------------------------------------------------------
- Raw text -