exabyte record size limit

Sam Fulcomer sgf at cs.brown.edu
Wed Feb 20 07:27:00 AEST 1991


In article <1991Feb18.175737.19866 at b11.ingr.com> mcconnel at b11.UUCP (Guy McConnell) writes:
>In article <64513 at brunix.UUCP> sgf at cs.brown.edu (Sam Fulcomer) writes:
>[In regard to Exabyte record size limits]
>
>>
>>The 8200 format writes 8 physical blocks of data (1024 bytes each, with 400 
>>bytes ECC and 16 bytes address) during each physical write operation. 
>
>    Actually,  there are 400 bytes of ECC,  14 bytes of address, and
>2 bytes of CRC per 1K block.  The drive writes more than the 8 1K
>blocks during each "physical write" in which a larger logical block
>size was specified.  Perhaps you meant during each rotation of the
>head during a write.

Ummm, doesn't the 16 bytes of address info include 2 bytes of CRC?

I consider an physical write operation to contain of only one
formatted track because a formatted track is the atomic unit
of physical data on the tape, and because (through no coincidence)
it is at this level that error detection (and write retry) is 
accomplished by the write driver circuitry via direct-read-after-write.  
 
>>point is called the "write motion threshold" and defaults to 240k.

>    It is called the "motion threshold" because it is equally valid
>for reads and writes and it defaults to 80H or 128KBytes.  It is
>Mode Selectable and the valid values are from 20H to D0H (32KBytes
>to 208KBytes).

I happened to be speaking of the "Motion Threshold", as it is called,
in the context of write operations (it's action is different in a read
context), and, in the firmware I've got, it defaults to 240k in a valid 
range of 0x1-0xf7h kilobytes. 

I'm sorry; I'll never again post numbers without rev-levels.

finis.



More information about the Comp.sys.sgi mailing list