Message-Id: <199704241125.NAA18276@grendel.sylaba.poznan.pl> Comments: Authenticated sender is From: "Mark Habersack" Organization: PPP (Pesticide Powered Pumpkins) To: Lorier Date: Thu, 24 Apr 1997 13:21:44 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: File Systems (was Re: Usage of directory entries Reply-to: grendel AT hoth DOT amu DOT edu DOT pl CC: alaric AT abwillms DOT demon DOT co DOT uk, opendos-developer AT delorie DOT com In-reply-to: Precedence: bulk Once upon a time (on 23 Apr 97 at 19:26) Lorier said: > >> Slooow! It seems really slow! > > > >I have to agree. Win95 does that. Perhaps because the heads aren't left > >near where they're most often wanted, or because FAT partitions never get > >ver fast anyway. I'd prefer to have a filesystem that isn't so subject to > >fragmentation so a defragger has little to do. > > Yeah, avoid the problem all togeather! Defraggers shouldn't be needed :) True. Take ext2fs for example - I shuffle decent amounts of data on my disks and yet after the last defrag 2 months ago I've got a defragmentation factor of 2%! > >(4) Design "automatic" diskette and CDROM drivers that adapt to the > > media formats, e.g. detecting Macintosh diskettes. So the IFS should > > start by doing a simple check "is this a valid FAT diskette", and even > > "does this have a known virus signature or characteristics of > > viruses?", then call each loaded driver until one recognises the > > format. > > Hmm, I think it would be nice to have it store ALL the drivers in EMS (if > possible), then Bank Switch in a driver, call it's "init" and if it can > return: Why EMS? XMS is much faster and efficient. But storing of all the drivers in the memory seems like a waste of space. No automatic insertion notification is available for FDDs - the file system can only be recognized on demand or at the first access to a new diskette. Loading an appropriate FS driver from HDD at that time is not that costly in terms of time! > 00 - Not Detected > 01 - Detected as BAD, do not mount (Virus checker etc...) > 02 - Detected and possible to mount. > 03 - Detected and possible to mount partially (mounted as ro for example). > > If the driver isn't in memory, it should be loaded... there should also be > info on order of loading as well. A return of 00 should try the next > driver, 01 should mark the disk as "unformated/*bad*", 02 shouldn't mount > any more, 03 should continue to see if there is another driver that will > support it more fully. I think that a better way is to maintain a database of FS signatures and their respective drivers. A system daemon should exist to detect on demand the FS type (as we cannot assume that they store their signatures in the same place as other FSs) by just peeking at the lead-in information of the FS (see GRUB for detection code). This costs less memory and time, IMHO. > >(5) Design a totally new file system that requires very little RAM > > yet is efficient (to be very efficient it might want more RAM), and > > capable of storing just about any extended attributes, ACL permissions, > > etc. If anybody wants to discuss details I have some ideas (which I'd > > love to simulate, if anybody has flexible software for the job). > > ANOTHER Fs? Hmm.. ok :) This should be a bit further down the track tho :) I think that it's a good idea - having own system means that you drive the van and you are not driven by someone else's moods. ================================================== Stand straight, look me in the eye and say goodbye Stand straight, we drifted past the point of reasons why. Yesterday starts tommorow, tommorow starts today And the problems seem to be we're picking up the pieces of a ricochet...