On Mon, 28 Jul 2003, Megan wrote:
> >It's a LOT easier (and much more efficient) to just implement an
> >allocation map.
>
> But not at all needed if you use a flat, contiguous file system.
Sure it's needed, because of the issues that you folks have been
discussing with regards to such a beast. It's clumsy and cumbersome to
deal with when you delete files or need to increase the size of a file.
> And remember, the question was asking for the simplest file
> system... and a block/sector/whatever allocation map and the
> associated code to handle it is not as simple as one can get.
The criteria is "simplest usable" and "practical" filesystem. I think an
allocation map is more usable and practical, but that's just my preference
having been initially exposed to filesystems with these features.
> Not to mention the fact that you need tables of pointers to the
> blocks so that a file can be reassembled, or read in order... and
> the risks to the whole file if the pointers are lost...
That's what FAT and ProDOS does, but I'm not suggesting that. The
allocation map I'm talking about keeps track of the free/used sectors on
the disk so you don't have to set aside large unused swaths of disk space
for each file.
> I can't tell you how many RT disks I've been able to recover
> from truly bad blocks in the directory by virtue of the fact
> that the RT directory structure is so simple...
The approach I initially suggested (linked-list sectors) is very robust as
well.
--
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 Mon Jul 28 2003 - 09:13:00 BST