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: Fri, 18 Apr 1997 21:24:25 +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
In-reply-to: <m0wIAP0-000Fm9C@hn.planet.gen.nz>
Message-ID: <861394882.116759.0@abwillms.demon.co.uk>
Precedence: bulk

On 18 Apr 97 at 21:56, Lorier wrote:

> >An extent based filer like VSTa uses or, I deduce, NTFS is (it uses
> >512 byte allocation units) can be more efficient, I think; disk
> >space is managed like malloc allocates blocks of RAM, in runs of 
> >sectors. Unless it gets really fragmented, this is smaller than having 
> >free-space bitmaps and indirection blocks and all that. And smaller
> >means faster, no? :-)
 
> Er, not always :) It's usually a trade off between Speed and Size, having to
> do it that way means you have to do mass calculations, and also trying to
> handle adding to to the end of a file is a problem if the next file is right
> at the end, thus leading to high fragmentation :)

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

Fragmentation can be solved by moving fragmented files (found when the filer
notes that accessing a certain file has entailed a lot of extent seeks)
into contiguous areas from time to time, a sort of background defrag that
works on individual files when it feels the need.
 
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