On Fri, 01 Apr 2016 21:11:56 +0100, Vir Campestris wrote:

On 29/03/2016 14:24, John Rumm wrote:
FAT was basically just a formalisation of what was inherited from
CP/M... it was not until MS hired a patent lawyer with the intention of
finding new way to monetise old intellectual property, that FAT was
even really acknowledged as being an item rather than just a bit of
technology that loads of people used. It main goal was simplicity and
lightweight implementation - as was demanded by the needs of the time.

This turns out not to be the case.

CP/M discs had a set of directory entries for the files. Each entry had
a few (8?) clusters described in it; if the file was big it had multiple
directory entries.

AFAICR, these 'extra' directory entries (CP/M 2.2) were known as
'extents'. As a method of keeping track of sectors (floppy disk storage)
used by a file, it just seemed overly 'clunky' and inefficient (however,
it did seem to offer some resilience against errors which may have been
mandated by the lack of a duplicate directory structure - at least I
can't recall any mention of duplication of this vital FS metadata).

I guess the standard 16(?) sectors or allocation units/clusters (It must
be over 3 decades ago when I last tried to study this stuff) per
directory entry was ample to allocate all of a floppy disk's storage
space to the maximum number of file entries (64?) such that they could
'waste' a directory entry slot or 3 for use as extents for larger files
which would reduce the number of files that could be stored anyway.


One of the boot up tasks for CP/M was to read all the entries, and build
a free space bitmap in memory. No need for chkdsk to find lost bits.

I never delved into CP/M 2.2 that deeply but that does seem a logical
task. However, I rather doubt it was to eliminate the need for a CHKDSK
like utility, so much as a way of speeding up write operations into free
space.

--
Johnny B Good