delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/04/25/08:54:02

Message-Id: <199704251241.OAA11865@grendel.sylaba.poznan.pl>
Comments: Authenticated sender is <grendel@[150.254.113.14]>
From: "Mark Habersack" <grendel AT hoth DOT amu DOT edu DOT pl>
Organization: PPP (Pesticide Powered Pumpkins)
To: alaric AT abwillms DOT demon DOT co DOT uk
Date: Fri, 25 Apr 1997 14:41:41 +0100
MIME-Version: 1.0
Subject: Re: Usage of directory entries
Reply-to: grendel AT hoth DOT amu DOT edu DOT pl
CC: Matthias DOT Paul AT post DOT rwth-aachen DOT de, opendos-developer AT delorie DOT com
References: <Pine DOT BSI DOT 3 DOT 96 DOT 970423142220 DOT 12655I-100000 AT hoth DOT amu DOT edu DOT pl>
In-reply-to: <861911953.0525097.0@abwillms.demon.co.uk>

Once upon a time (on 24 Apr 97 at 20:08) Alaric B. Williams said:

> > mkisofs, for example) - that way the defragmenter is either not run at all
> > or its work is wasted everytime the file system is written with the huge
> > amount of data output from mkisofs?
> 
> In which case, run it like a parallel garbage collector - match it to the
> rate of garbage creation.
> 
> A garbage collector is a process that deallocates memory automatically. With
> a GC, you never call free() - you just leave memory lying around, and the GC
> cleans up after you. Now, a parallel GC runs as a seperate thread. The
> system looks at the amount of memory being allocated by the program, and the
> amount of memory being found as unreachable by the GC. If the program is
> allocating faster than the GC is freeing, the GC gets a priority boost, and
> vice versa. In this case, we take some metric of the rate at which files are
> fragmenting, and use it as a basis for the clock ticks allocated to the
> defragger.
mmm... sounds sensible. Do you know of any GC already working somewhere?

> > I agree here - the error detection would be nice. But, IMHO, it would be
> > hard to make the defrag work in concert with swapfile managers and caches.
> > I don't know... just my opinion...
> 
> Well, it would go outside the cache, using direct reads and writes, since
> there is little benefit in caching it's activities. Therefore, it would need
> to notify the cache of things being shuffled around. To this end, we could
> cache blocks with addresses relative to files rather than disk sectors...
> ie, "this cache block is the 3rd sector of file handle X". So when things
> shift about, nothing gets lost!
That needs a great deal of memory to be held in a locked area...

> Swapfiles should be allocated from a fixed, unmoveable, solid block anyway,
> IMHO.
And what about the 'flexible' swapfiles - they out of definition cannot be 
stored in solid blocks?
==================================================
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 -


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