CP/M directory entries

On 04/13/2012 04:28 PM, Jules Richardson wrote: For practical purposes there are limits. those are the amount of buffer to directory entries, and the time it take to do a linear search. there was only one standard 8"SSSD with resulted in 64 directory entries, 1kbyte allocation size, and a whopping 241allocation block (241K of storage). that averages to 4 allocation blocks or 4K per file and either the disk is full or the directory fills. The other limit is a logical device maximum is 65535 128 byte logical sectors or 8191.875 Kilobytes. since the smallest allocation size allowed for disks over 255Kbytes is 2K that means the largest directory will be 4096 entries (at 32bytes per entry or 128Kbytes of the disk). That represents the wall as far as how high can you go. The lower end is a 82kb (NS* SSSD, and others) where 32 entries eating 1KB of disk and 81K left for storage. If there is a pattern that emerged its that many CP/M files were in the 4-16K size and for the larger disks allocation sizes of 2K or 4K were common with directory sizes based on a range of 4K to 16K per file. So I'd see 5.25" DSQD (720-800k) disks set up to have directories accommodating 128 or 256 entries and the larger hard disks usually set for 512, 1024 or maybe 2048 entries. There may have been some ill conceived few that had way to few entries way to many for the media. I did see on 8MB disk with 16K allocation size (kinda large for practical use) and as a result only 512 entries were possible but the vendor did 1024 (it would break at the 512th file added). NOTE: That was for CP/M-80 though V2.x, cpm 3 fixed the math so logical devices could go to 32mb. At 32MB a 8192 entry directory might make sense but to get a 32MB disk you also used the larger allocation sizes like 8 or 16K and that again limited the number of possible files to less. Some of the CP/M clones P2dos, Suprbdos, and ZPR could allocate devices as large as 2GB but then file sorting and directory times could be painfully slow. That and with a relatively flat directory more than 1024 entries tend to be more annoying than useful. The largest I'd done was a CP/M clone using Suprbdos and a 2GB CF partitioned as four 128MB, and two 512mb logical devices. Those proved to be not manageable as the 512MB partitions with 16K allocation block size the best plan was 32,768 entries. I gave up on that and found a 32MB CF and used that as one 16MB (1024 entries) and four 8MB (512 entries) which has more reasonable proportions. FYI: even with the Suprbdos hash doing a DIR of the 16mb partition was a minute of waiting thing even with a 10mhz Z80 and banked ram. It took 32KBytes of data shuffling (read and parse) for that 1024 directory entry. I didn't get into the fact that CP/M maintains ALLOC Bit map in ram and its size is 1 bit per allocation block so a 8MB disk has 8192 ALLOC bits and need a 1K space (per logical drive) in ram to keep track of them! With 64K of addressable space that alone is painful. There is also a directory buffer but usually thats limited to 128bytes. and if the device is not self cached (IDE,CF are) then the BIOS also has a host sector cache for deblocking and usually that 512or 1025 bytes. So an old style 8mb hard disk could easily hit the system for 1.5k of scarce ram. Allison