27 Jul
2003
27 Jul
'03
1:32 p.m.
On Sun, 27 Jul 2003, Sean 'Captain Napalm' Conner wrote:
That's because it is using 512 byte allocation units. To reduce the
allocation block map size you'd need to up the allocation unit size.
At any rate, with an 8GB drive as an example, the size of the map relative
to the total disk space is negligible (a fraction of a fraction of a
fraction of a percent), and searching the allocation map can be made more
efficient using hash algorithms or simple pointers to the beginning of the
next available string of allocation blocks.
I still think it's a better and more efficient way to go, and not much
more work to code than the simpler schemes being suggested.
--
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 *
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.
But at some of the sizes being used, the use of a bit map to track
free space becomes problematic---with an 8G drive, that's 2M of space just
for the bitmap, which takes time to search. And after reading