>One thing I've considered in using the FAT filesystem drivers is, "Why do
>we need to have so many modules for this?" This is an option that may have
>already been looked into, but I figured I'd put it out there and see what
>people thought. What if, instead of having the base FAT module and an
>MSDOS fs module and a VFAT fs module that load on top, have the FAT module
>be extendable?
The simple reason: why make people pay the cost of having code in the
kernel that they don't need?
Albert Cahalan <albert@ccs.neu.edu> writes:
>By default, the name should be "fat" and it should autodetect
>the vfat and umsdos extensions.
I'm not too thrilled with this idea--you could certainly modify supermount
to look for the --linux-.--- directory and then remount as umsdos. However,
I can have umsdos directories far down my hard disk, so would autodetect
code do a full search of my partition looking for a --linux-.--- file?
I have my laptop setup so that parts of a partition are umsdos enabled
and other parts are not.
Similarly, detection of vfat filenames is not simple. Do I have to look
all over the disk just to find a long filename? Many times, Win95
installations have only 8.3 names because Microsoft still tends to
squeeze everything into 8.3 names. So how do I know the disk is vfat?
(Actually, it may be easier now. In the past, WinNT didn't write out
a long filename if a filename fit into an 8.3 name. I think W95 always
writes out a long filename as well.)
>The gross vfat filesystem requires
^^^^ (I think you mean umsdos)
>a gross kernel hack: look for a win* directory with long filenames.
>Then look for a linux directory and do the umsdos pseudoroot.
>The umsdos pseudoroot should always operate to make recovery easy.
>Without the pseudoroot, many more symlinks break.
I've been very happy to have had umsdos around. When I had a laptop with
a small harddrive, I couldn't afford to create a separate ext2 partition.
It might be a hack, but it has been a very useful hack for me. And I
presume you will really hate my work on uvfat--sort of a hack on top of
a hack.
>The "msdos", "vfat", and "umsdos" names can be equivalent to
>"fat" with mount options to disable or force various features.
So I need to waste all the space taken up by umsdos when all I really
need is a simple msdos filesysetm? Sounds rather wasteful to me.
>There is a need to support the new FAT32 filesystem.
Its coming. I have it working for at least reads. Now it is time
to check writes.
>Thought: the FAT filesystem code has grown too big and complex.
>Nobody would want to rewrite it, because then all the strange
>code must be tested again - maybe. Must we still support DOS 3.1
>disk manager hacks? The text file translation makes the code
>complicated and very ugly. Microsoft has added new things recently,
>including FAT32 and a dirty flag. I think the linux driver would
>run much faster if it kept the whole FAT in RAM and built some
>decent data structure in RAM to shadow the FAT data.
>
>Right now, mtools is 4x as fast as the kernel filesystem.
>I tested a file copy of 700 kB on a 1.44 MB floppy disk and
>a file copy of 4 MB on a 96 MB Zip disk. In both cases,
>mtools was about 4x faster.
I thinks this has merit. I'd be interested in finding out why this is
the case. With a 32KB cluster size, I've seen the fat filesystem become
completely unuseable on my laptop. I was using umsdos, and my machine
would take about 5 minutes just to completely boot up. I repartitioned
the drive to use 8KB cluster size, and then umsdos worked quite well.
I wonder if performance is bad everywhere or just in certain cases.
It sounds like performance is poor overall, not just in certain cases.
Keeping the fat in memory could help, but you would need to be careful
with FAT32 disks. The fat could potentially get rather large. I'm not
sure about the too big and complex comment however. I checked mtools-3.0,
and it has a total of 5782 lines of C code (not including any m*.c files).
Compared, the fat directory has 3358, the vfat code is 1641, and the
msdos code is 867. Of course, mtools has to handle tasks that are
handled in the fs layer of Linux, so some code will be taken up by
that. So probably the fat code is too big and complex, but it isn't
perfectly clear if that is the case.
Gordon Chaffee
plateau.cs.berkeley.edu