[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:5.267 / U:4.296 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site