On Sun, 27 Jul 2003, Megan wrote:
> >There also needs to be a map somewhere specifying which
> >sectors are free/used.
>
> That can be a lot of overhead, and can take up a fair amount of disk space
> depending on how it is implemented, and with each directory entry having
> start and size, it isn't needed.
Using one bit per byte (or word) you can store the status of up to 2048
allocation units (sectors, blocks, whatever) in 256 (8-bit) bytes of disk
space. So assuming your allocation units--let's call them "sectors"--are
256 bytes, a map taking up one sector can give the free/used status for a
2048 sector disk, or a disk with a half-megabyte capacity. Each
additional sector assigned for use in your map gives you another
half-megabyte of allocation information. Not bad.
> With the contiguous file system on RT, one *can* extend a file, though it
> either takes intimate knowledge of the directory structure on the part of
> the program, or extra code to open a new copy of the file (larger), copy
> everything from the old version to the new, closing the old, updating the
> new one and closing the new. A program with intimate knowledge of the
> directory would have to find the entry for the file, check the next entry
> and if it is an empty space, it could increase the file size (up to the
> size of the empty) so long as it decreased the size of the empty by the
> same amount. Of course if the next entry is not empty, then you have to
> revert to the first method.
It's a LOT easier (and much more efficient) to just implement an
allocation map.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
Received on Sun Jul 27 2003 - 18:08:00 BST