delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/04/23/03:52:24

Message-Id: <m0wJwRJ-000FnVC@hn.planet.gen.nz>
Date: Wed, 23 Apr 97 19:26 NZST
Mime-Version: 1.0
To: physmsa AT cantua DOT canterbury DOT ac DOT nz (Mr M S Aitchison)
From: Lorier <lorier AT ihug DOT co DOT nz>
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

>> 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 :)

>What I would like the system to do (as an option; if you have enough
>RAM, etc) is to record what files are often needed after other files,
>to sensibly preload or rearrange sectors.
>
>I think the priorities should be:
>
>(1) Decide on a system (lets call it IFS) to which filesystem-dependent
>    drivers can be added (with the least source changes from Linux the
>    better!) This should be able to be used on generic DOS (albeit with
>    some limitations) but certainly tie in with OpenDOS security.

that sounds like a nice idea... 

>(2) Start with at least ext2fs and vfat drivers for it.

fat & ext2fs, definately :)

>(3) Invite others (especially commercial/shareware vendors of existing
>    hpfs, etc drivers) to write using it. Make sure the licencing
>    allows them to distribute the IFS with their product to help it
>    become popular.

most definately :)

>(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:

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.

>(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 :)

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019