[lkml]   [1996]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFC: Modified FAT filesystem driver?

From: Gordon Chaffee <>
> Derrik Pates <> writes:
>> One thing I've considered in using the FAT filesystem drivers is,
>> "Why do we need to have so many modules for this?"
> The simple reason: why make people pay the cost of having code
> in the kernel that they don't need?

I would favor a solution with two drivers. One has everything,
and the other only has plain 12-bit and 16-bit DOS filesystems.

> Albert Cahalan <> 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.

It should look in the most likely places. It is always a good idea
to let the user force and prevent detection, but autodetect should
be the default for type "fat", which is not mountable now.

> Similarly, detection of vfat filenames is not simple. Do I have
> to look all over the disk just to find a long filename?

You look in windows, win95, and winnt.

> Many times, Win95 installations have only 8.3 names because
> Microsoft still tends to squeeze everything into 8.3 names.

Programmer brain damage. :-)

I think you can always find a long filename in win*/desktop,
or whatever they call it.

> 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 access time might be filled in.

>> The gross vfat filesystem requires
> ^^^^ (I think you mean umsdos)

No, I mean vfat (well, both actually).

>> 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.

I don't mind a gross hack when it is needed. I was actually suggesting
one: autodetection of the FAT extensions. It is gross, but very useful.
It would really help Linux distributions. Linux would also act right
when a DOS partition gets Windows 95 installed.

>> 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 no simple msdos filesystem. I'd like one that just supports
12-bit and 16-bit FATs and 512-byte sectors. There would not even
be hooks for vfat and umsdos.

With that need taken care of, the standard version could become
as bloated as xemacs. :-)

>> 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.
> Keeping the fat in memory could help, but you would need to be careful
> with FAT32 disks. The fat could potentially get rather large.

If the kernel could mmap the FAT as a file, normal memory
management would take care of that problem. Isn't there a
trick that makes that work? I seem to remember that you
could save and restore one of the segment registers, or the
Linux 2.1 and non-i386 equivalent.

Advanced tricks would be easy with swappable kernel memory. If we
had that, the FAT could be shadowed in a B-tree structure that gets
swapped out. Maybe a hook into the swapper (not only for this!)
could let less used bits of the FAT data get thrown out when memory
runs low. (this assumes reads are more common)

 \ /
  Last update: 2005-03-22 13:38    [W:0.044 / U:1.520 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site