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 *