hugh@hcrvx1.UUCP (Hugh Redelmeier) (08/07/85)
While examining the directory on some Osborne I disks, I noticed a couple
of things that puzzled me.
The first extent of some files (they seemed to be big ones) was
sometimes numbered one, instead of zero (the number of the extent is in
the field named "ex", at offset 12). Why? Is this legal?
The record count field was not an exact record count for the extent (nor
could it be). The record count is constrained to be in the range 0
through 128, but an extent can hold up to 256 records. What are the
rules for resolving this? The CP/M manual does not seem to discuss this.
Hugh Redelmeier (416) 922-1937
{utzoo, ihnp4, decvax}!hcr!hughgrayson@uiucuxc.Uiuc.ARPA (08/16/85)
In a directory entry are 16 bytes for storing allocation group numbers of
the extent. If the number of allocation groups is larger than 255 then
these numbers take up two bytes, else one byte. Now, once you know the
size of an allocation group (typically 1K or 2K) you can compute how much
disk space one directory entry can refer to - this typically comes to 16K
or 32K. If it is 16K or less, then the maximum number of 128-byte sectors
in that space is 128 or less, so the field giving the number of sectors
holds that number just fine, and extents are numbered sequentially.
On the other hand, if it is 32K or more, then the maxmimum number of 128-
byte sectors is 256 or more. In this case we define an extent to be 16K
of file space, and each directory entry will refer to more than one extent.
The extent number field of the directory entry will contain the number of
the LAST extent referred to, and the number-of-sectors field will indicate
the number of sectors in that last extent. The extents other than the
last one all contain 128 sectors, so everything is determined.
Another way to think about it is this. Suppose 2**(n+7) is the number of
sectors one directory entry can reference. Then we have n bits of overflow
from the number-of-sectors field (7 bits) and those n bits are stashed in
the low order part of the extent-number-field. What makes this not QUITE
right is that on occasion the 8-th bit of the number-of-sectors field is 1,
and then that bit is the overflow bit for the other n+7 bits.
uucp: {ihnp4,pur-ee}!uiucdcs!uiucuxc!grayson
Dan Grayson, Math Dept, Univ of Ill, Urbana 61801mathur@alberta.UUCP (Ambrish Mathur) (08/19/85)
>While examining the directory on some Osborne I disks, I noticed a couple >of things that puzzled me. > >The first extent of some files (they seemed to be big ones) was >sometimes numbered one, instead of zero (the number of the extent is in >the field named "ex", at offset 12). Why? Is this legal? > A 'logical' extent in CP/M(tm) is of size 16K (128 records of 128 bytes each). In the simplest case when file space allocation is done in blocks of 1K, each physical extent holds 16 1K block entries (128 records) and is the same as a 'logical' extent. In this case the extent numbers will be seen to be 0, 1, 2, etc.. However, when disk space is allocated in larger units (2K, 3K,.. 16K), each physical extent actually corresponds to >128 records. In this situation, after 128 records have been written to an extent, the same extent , say 0, becomes extent no. + 1, ie 1 in our case and the record count is reset to 0. This goes on until all 16 allocation table entries are full, then a new physical extent is created. >The record count field was not an exact record count for the extent (nor >could it be). The record count is constrained to be in the range 0 >through 128, but an extent can hold up to 256 records. What are the >rules for resolving this? The CP/M manual does not seem to discuss this. The above explanation also clears this. --Ambrish Mathur ...ihnp4!alberta!mathur