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