big SCSI == LOST_DATA????

[Martin Golding]

In <1991Mar13.153825.22240 at banana.fedex.com> bill at banana.fedex.com (bill daniels) writes:

>An front-page article in the March 4, 1991, issue of _Digital News_ deals
>with problems associated with using large (> 1.2G) SCSI disks under Ultrix
>(through 4.1) and VMS.  The reason given is adherence to SCSI Group 0 commands.
>Supposedly, the group 0 commands break down when referencing large addresses.
>My question is:  Does this address wraparound problem arise any time one
>addresses the last portions of a disk OR only if the disk is considered
>one large (read Ultrix "c") partition?  Will the same problem appear if the
>latter part of the drive is a smaller "h" partition?

The seek, read and write commands are organized as follows:
(Note obnoxiously correct bit and byte order)
((Flame me in person, nobody else needs to be annoyed))

byte	bits	content
0		command: read is 0x08, write is 0x0A, eg.
1	0-2	Logical unit (up to 8 units per logical controller)
1	3-7	high bits of sector address
2		middle bits of sector address
3		low bits of sector address
4		sector count
5		[irrelevant control stuff]

SO you have 5 + 8 + 8 bits of sector address, plus your sectors are 512
bytes for 9 bits, so you have 30 bits with which to address bytes.
2e30 is 1G (1 * K^3) or 1.07 billion. It should be considered a major
bug that the driver wraps around; but it's built into the simple SCSI
command set not to address more data than that.

Partitioning would do you no good, unless the controller itself can
split a physical drive into two logical units. The limit is in the
command that passes across the SCSI bus, and can't be corrected within
the DEC OS.

Besides, you should know better than to put all that valuable data under
one slow and vulnerable arm. 


Martin Golding    | sync, sync, sync, sank ... sunk:
Dod #0236         |  He who steals my code steals trash.
{mcspdx,pdxgate}!adpplz!martin or martin at adpplz.uucp