delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/04/24/19:51:49

Comments: Authenticated sender is <alaric+abwillms AT sdps DOT demon DOT co DOT uk>
From: "Alaric B. Williams" <alaric AT abwillms DOT demon DOT co DOT uk>
To: grendel AT hoth DOT amu DOT edu DOT pl
Date: Thu, 24 Apr 1997 20:08:15 +0000
MIME-Version: 1.0
Subject: Re: Usage of directory entries
Reply-to: alaric AT abwillms DOT demon DOT co DOT uk
CC: Matthias DOT Paul AT post DOT rwth-aachen DOT de, opendos-developer AT delorie DOT com
References: <861739004 DOT 1127939 DOT 0 AT abwillms DOT demon DOT co DOT uk>
In-reply-to: <Pine.BSI.3.96.970423142220.12655I-100000@hoth.amu.edu.pl>
Message-ID: <861911953.0525097.0@abwillms.demon.co.uk>

On 23 Apr 97 at 14:26, Mark Habersack wrote:

> > Seriously, stop and think about it. The defrag thread can run purely 
> > in idle time, ie it's at a REALLY LOW priority. OTOH, it sits there

> OK. So it has a low priority and, as such, runs last of all the processes. Now
> think about a situation when this defrag task is being pushed back to the
> bottom by other ones which constantly mess with some files (say 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.

>  > invisibly sorting the disks out - so disk access is FAST and NICE!
> > What's more, it might find disk errors and things while it's at it,
> > and raise suitable alerts.

> 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!

Swapfiles should be allocated from a fixed, unmoveable, solid block anyway, IMHO.


ABW
--
Alaric B. Williams (alaric AT abwillms DOT demon DOT co DOT uk)

   ---<## OpenDOS FAQ ##>---

Plain HTML: http://www.delorie.com/opendos/faq/
            http://www.deltasoft.com/faq.html

Fancy HTML: http://www.deltasoft.com/faq0000.html

- Raw text -


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