delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/02/07/14:42:43

To: opendos AT mail DOT tacoma DOT net
Subject: Re: [opendos] Filesystems
Message-ID: <19970207.111937.4959.0.chambersb@juno.com>
References: <Pine DOT GSO DOT 3 DOT 95 DOT 970206220435 DOT 600D-100000 AT sparkie DOT gnofn DOT org>
From: chambersb AT juno DOT com (Benjamin D Chambers)
Date: Fri, 07 Feb 1997 14:17:42 EST
Sender: owner-opendos AT mail DOT tacoma DOT net

On Thu, 6 Feb 1997 22:09:29 -0600 (CST) "Colin W. Glenn"
<cwg01 AT gnofn DOT org> writes:
>And every time the driver dies, you access the drive, and smack 
>yourself
>as the lag of the software, discovering a gravestone instead of a 
>driver,
>resurrects the driver before accessing the drive.  So you boost the 
>life
>of the driver, which then consumes more resources waiting to die 
>again.
>
>Good idea.
Do I detect a hint of sarcasm?

And yet a cacheing system operates on EXACTLY the same principle - access
what's needed when needed, dump it when  it hasn't been accessed for a
while.  Alternatively, you could have a set number of systems loaded at
once, this would be equivelant to having cache lines, dumping them when
new data is read in, et cetera.

So, say, you set a max of 2 drivers loaded at once.  If all you ever use
is FAT and ext2fs, then no problem - you'd never have a lag.  If you
have, say 10 drives mounted with a different fs on each, you could
encounter a lag - but how many people run a program that accesses 10
different drives at once?  There are certainly flaws in this system, and
their are strengths.  Personally I like it better than being limited to
FAT, and I'd like to hear if there are any REAL reasons this couldn't be
done.

...Chambers

>
>

- Raw text -


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