[comp.sys.dec] big SCSI == LOST_DATA????

bill@banana.fedex.com (bill daniels) (03/13/91)

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?
-- 
------------------------------------------------------------------------------
these ravings are in no way sanctioned by federal express corp

bill daniels			| voice:  (901)797-6328

conroy@npi.com (Pat Conroy) (03/15/91)

In article <1991Mar13.153825.22240@banana.fedex.com> bill@banana.fedex.com (bill daniels) writes:
>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?

The group 0 read and write commands have 21 bits to address a logical block
on the disk.  Therefore, the last logical block that you can address is...
2,097,151.  At a 512 byte block-size that gives you 1,073,741,824 bytes that
you can address.  Since this restriction is at the SCSI interface level, 
you can't just repartition the drive into little chunks and access all of it.
You are stuck with 2**21 blocks per device, so partition accordingly.

The group 1 read-extended and write-extended commands have 4 bytes of address.
This address is either absolute, or in the case of linked commands, relative
to the last accessed block.  At a 512 byte block-size, this yeilds about
2.1TBytes of absolute addressable storage.  I don't think we'll see this passed
in the near future.

Opinion:  That "User data at risk using 1.2GB drives"  (I paraphrase) headline
is a gross overstatement of the problem.  The problem only occurs when you use
a 512byte block-size on the device (some OEMs use 1k), and only with some 1.2GB
disks (unformatted capacity).  For example, the Fujitsu 1.2 has slightly more
capacity than the Seagate 1.2.  This extra amount pushed the Fujitsu over that
2**21 limit.  The real story should have been "Disk Resellers Negligent in 
Peddling Disk Drives."  People should understand what they sell.

-- 
Pat Conroy			Mail: conroy@npi.com
Systems Engineer		Voice: 708-325-4151
National Peripherals, Inc.	Fax: 708-325-4230

usenet@bellcore.bellcore.com (Poster of News) (03/15/91)

In article <1991Mar13.153825.22240@banana.fedex.com> bill@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 problem is real and does NOT depend on the file system section number.
The driver in many systems cannot (by using type 0 commands) access
block numbers that require more than 21 bits = ~1.2Gbytes.

File system sections are basically offsets added to the desired block number:
for example, if section H starts at block 10000, asking for block 3
of section H is mapped by the operating system to 10000 + 3.  The
disk drive only sees a request for block 10003, it doesn't know of sections.
So in your example, any reference to that section H will clobber your
drive's low block numbers.

BTW: Since the address in the type 0 commands is a block address,
not a byte address, the problem will appear later (i.e. with bigger
drives) on systems that format disks with larger block sizes (i.e., 1024)
But in any case, the right solution is to have the kernel generate
the larger command when appropriate.

Marc Pucci
marc@bellcore.com

PS:  There is yet another problem waiting in the wings for unix user's
since the read/write seek pointer is limited to 31 bits, it will
soon be impossible to make random access to very large disks.

martin@adpplz.UUCP (Martin Golding) (03/15/91)

In <1991Mar13.153825.22240@banana.fedex.com> bill@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@adpplz.uucp