Messages in this thread |  | | From | Albert Cahalan <> | Subject | Re: RFC: Modified FAT filesystem driver? | Date | Fri, 22 Nov 1996 19:35:17 -0500 (EST) |
| |
From: Gordon Chaffee <chaffee@odie.cs.berkeley.edu> > Derrik Pates <dpates@cavern.nmsu.edu> 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 <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.
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)
|  |