Date : Sun, 13 Mar 1988 20:02:21 GMT
From : portal!cup.portal.com!dgood@uunet.uu.net
Subject: CP/M disk Directories
> The scenario: Disk B: is a DSDD 48 tpi drive. It uses 8-bit allocation
> groups, so 16 groups can be allocated in one directory extent. The group
> size is 2k, so each extent can address 32k. That, I have no problem with.
> What I have problems with is how the damn files are represented in the
> directory. A short example session follows.
There is some confusion here between about the concept of an extent.
Originally, in cp/m 1.x (how's that for comp.archaeology) an extent
was, by definition, 16k. This was because each dir entry showed the
location of 16 groups x 1k per group.
With cp/m 2.x came a more flexible arrangement. Groups can be up to
16k each. It also became possible to use either eight or sixteen bit
directory addressing for each group; each directory entry still
contains 16 bytes of group addresses, which may now address either
eight or sixteen groups.
Thus an extent (the amount of a file handled by a single directory
entry) became variable. However, to maintain compatibility with the
earlier versions of cp/m, the physical directory entries continue
to consider an extent as 16k (ALWAYS). In other words, we now have
a physical extent, which might contain as much as 128k (16k group x
8 groups/dir entry), but our directory extent byte shows logical
extents, which are always 16k! In your example the logical extent
is 16k, but the physical extent is 32k.
> B0:WORK>save 511 test.fil s ; create a file in 2 extents
> ; minus 1 record
Note that you have saved 2 physical extents, but 4 logical extents.
> B0:WORK>stat test.fil ; check it out
>
> Recs Bytes Ext Acc
> 511 64k 2 R/W B:TEST.FIL ; Ok, 511 recs in 2 extents
> Bytes Remaining On B: 154k
Yes, 2 physical, 4 logical extents
> B0:WORK>stat b:dsk:
>
>
> B: Drive Characteristics
> 3120: 128 Byte Record Capacity
> 390: Kilobyte Drive Capacity
> 128: 32 Byte Directory Entries
> 128: Checked Directory Entries
> 256: Records/ Extent ; Wait! How is this done?
> 16: Records/ Block ; Isn't the RC byte limited to
> 40: Sectors/ Track ; a maximum of 80h records?
> 2: Reserved Tracks
The RC byte shows the number of records (max 80h) in the LAST logical
extent for that directory entry. Here, we'll have two logical extents,
ext 0 & ext 1, for the first dir entry.
> ; Ok, now we look at the directory...
>
> B0:WORK>
>
> DU3 B0? s5
> Group = 00:04, Track = 2, Sector = 5, Physical Sector = 4
>
> vv-------------- extent #1?
> vv vv-------- 80h records in this
> vv vv extent?
> vv vv
> 60 00544553 54202020 2046494C 01000080 |.TEST FIL....|
> 70 090A0B0C 0E0F101E 393A3B4E 5C5D5E5F |........9:;N\]^_|
^ --extent #0-- ^ ^ --extent #1-- ^
Since we have filled logical ext #0 and are into logical ext #1,
we know that we have 80h records in logical ext #0. The RC byte
shows 80h records in logical ext #1, the last logical extent in
the dir entry. Remember that the extent byte shows the LAST
logical extent in that directory entry, and the RC byte shows
the number of records in that last logical extent.
> DU3 B0? +d
> Group = 00:05, Track = 2, Sector = 6, Physical Sector = 5
> vv-------------- extent #3?
> vv vv-------- 7fh records in this
> vv vv-------- extent?
> vv vv
> 00 00544553 54202020 2046494C 0300007F |.TEST FIL....|
> 10 60616263 64656667 686E6F70 71727374 |`abcdefghnopqrst|
^ --extent #2-- ^ ^ --extent #3-- ^
Again, 80h records in (full) logical ext #2, 7Fh records in logical
ext #3.
Dave Goodman dgood@cup.portal.com