Message-Id: <199704251241.OAA11865@grendel.sylaba.poznan.pl> Comments: Authenticated sender is From: "Mark Habersack" 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 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT 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: In-reply-to: <861911953.0525097.0@abwillms.demon.co.uk> Precedence: bulk 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...