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: Lorier <lorier AT ihug DOT co DOT nz>
Date: Sat, 19 Apr 1997 20:33:32 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: FileSystems & Fragmentation.
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
In-reply-to: <m0wIPwy-000Fm3C@hn.planet.gen.nz>
Message-ID: <861478231.1014478.0@abwillms.demon.co.uk>
Precedence: bulk

On 19 Apr 97 at 14:32, Lorier wrote:

> >To extend a file, just increment that extent's length counter until you reach
> >the next extent, then start with a fresh extent. Easy peasy?!?!?
 
> Yeah, but allowing one cluster to house two (or more) files adds complexity
> I don't think you'd want :)

But there aren't clusters any more. Just sectors. My prototype 
implementation starts the first sector of each extent with an 8 byte header
containing two 32 bit integers: the number of data sectors in the extent, 
and the number of free sectors. The rest of this first sector is the first
data header.

To format a disk, write a single sector containing an extent header reading
"zero data, N free", where N is the size of the disk in sectors.

The first extent created on the disk is that root extent, except that the
data count is increased, and the free count decreased.

The next extent is created by setting the root extent's free sectors field to
zero, and creating a new extent header after the first extent's data.

The extent headers are cached, since they are walked along like a linked list
quite often.

I'm starting to build a file abstraction layer on top that allows the creation
of random and serial files. Random files have rarely changing sizes, and get
allocated from the largest available extent. Serial files are created
once as a single long byte-dribble output session, then read as many times
as necessary, again in sequential form.
 
> It would be nicer just to have a file system that doesn't require defraging.
> If OpenDos/32 was Multithreaded then having a low priority thread to slowly
> defrag files that are badly fragmented would be nice.

That's what I was on about!


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