Mail Archives: opendos/1997/04/25/00:28:24
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 :)
- Raw text -