CP/M file limits

[whartung]

CP/M 2.2 had a 64 file directory limit, across users. Were there any that allowed more? Did CP/M 3 allow more? Or was it a floppy limitation and hard drives had a different limit?

 

[durgadas311]

The max number of directory entries (not exactly the same as max number of *files*) was an attribute of the disk format, a.k.a. DPB. Many vendors had formats that allowed more than 64 directory entries. There was nothing built-in or hard-coded in CP/M 2.2. with respect to number of directory entries.

 

[krebizfan]

The CP/M Plus System Guide on page 43 explains the maximum number of directory entries. There can be up to 16 blocks allocated to directory entries. Since each directory entry has 32 bytes, divide the byte size of the block in half to get the maximum number of directory entries available to the drive. That gives a theoretical maximum of 16K directory entries. Note that some versions* of CP/M limit the directory scan to 128 directory entries for a given user area so very large numbers of directory entries may be inconvenient.

* At least that seems to the case for Amstrad's CP/M.

 

[durgadas311]

CP/M searches all directory entries specified in the DPB, but large/huge directories can be very inefficient. CP/M Plus allows for directory hashing, which can speed up that search quite a bit. Note that the directory blocks specified in the ALV0 bytes of the DPB are just reserved space. The number of directory entries searched is the DRM field of the DPB.

 

[whartung]

Yea, I'm working with z80pack and it's default 8" drive "floppies".

 

[krebizfan]

Z80pack uses 1024 directory entries for the 4MB hard drive and 8192 directory entries for the 512 MB hard drive which means it only allocates one block to the directory entries. About as efficient as possible under CP/M.

 

[durgadas311]

Z80pack uses 1024 directory entries for the 4MB hard drive and 8192 directory entries for the 512 MB hard drive which means it only allocates one block to the directory entries. About as efficient as possible under CP/M.

the 1024 or 8192 directory entries are the numbers that affect efficiency. The number of blocks does not affect efficiency. One (very large) block still requires reading a lot of sectors and searching the directory entries. For CP/M Plus, the directory is hashed on the first pass ("login") and after that the searches will be fast - provided the "vendor" implemented directory hashing. Because harddisks are (typically) not removable, it also saves on directory checking (and associated checksum space).

The "standard" single-density ("IBM format") 8" floppy has 64 directory entries, but other formats are possible. Typically, the number of directory entries is based on (computed from) the number of allocation blocks, but the number may not be satisfactory for all uses - it depends on the number of small vs. large files in your particular disk image(s). A one-block (smallest possible) file takes up one directory entry, and on some formats you will run out of directory entries before you've used all the allocation blocks.

 

[krebizfan]

At least one allocation block must be assigned to directory entries. It wouldn't make sense to leave part of that block unallocated by choosing a smaller number of directory entries than would fit in the block. The whole CP/M logic does break down on larger drives but a maximum effort set of directory entries would need 512K and be quite slow on any period CP/M machine.

Having the average file expected to need 4 blocks out of the 8 referenced in a directory entry seems like a good compromise for the floppy formats.

 

[durgadas311]

A directory entry references either 16 or 8 blocks, depending on a total number of blocks on the drive (8-bit or 16-bit block numbers). for harddisks, it is usually 8 because of the larger number of blocks. But, the blocks themselves are also larger so it is more likely that a given file will contain only one block. Floppies are much more likely to have 16 blocks per entry, as does the single-density 8" "standard" format - which is using the smallest block size. It's a trade-off. Several variables need to be considered when designing a DPB, and no single format is going to work perfectly in all situations.

 

[Chuck(G)]

Floppies can be all over the place; 8 or 16 bit block numbers and a few that use 8 bit block numbers but only the first 8 in an extent. Recall also, the interesting phenomenon of multi-extent "sparse files", where the virtual size of a file is larger than the physical space it occupies.

At some point, I thought that CP/M would do a directory search until 12 bytes of E5 in the extent entry was located. Since that's not a normal deleted file, it must be the end of the used part of the directory. But maybe I've got that confused with a different OS.