Comments: Authenticated sender is From: "Alaric B. Williams" To: grendel AT hoth DOT amu DOT edu DOT pl Date: Thu, 24 Apr 1997 20:08:15 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT 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: Message-ID: <861911953.0525097.0@abwillms.demon.co.uk> Precedence: bulk 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