Message-Id: Date: Fri, 25 Apr 97 16:19 NZST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: grendel AT hoth DOT amu DOT edu DOT pl From: Lorier Subject: Re: File Systems (was Re: Usage of directory entries Cc: alaric AT abwillms DOT demon DOT co DOT uk, opendos-developer AT delorie DOT com Precedence: bulk At 01:21 PM 24/04/97 +0100, Mark Habersack wrote: >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%! yep :) something like a news server must go through heaps of files and end up creating lots of fragmenttation :) >> >(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. Hmm, possibly, but I don't think that all FS's are going to be that nice :) that and it's nice to be able to select the "best" driver for the job :) But I agree, (notice I said load it), and chances are your going to load a FS that is already in memory. >> >(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. True, however there are a lot of good FS's for us to start with :)