Mail Archives: opendos/1997/04/24/07:32:36
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...
- Raw text -