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
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
co@etek.chalmers.se (Christer Olsson) (03/18/91)
In article <575@adpplz.UUCP> martin@adpplz.UUCP (Martin Golding) writes: >In <1991Mar13.153825.22240@banana.fedex.com> bill@banana.fedex.com (bill daniels) writes: > > >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. > Do you know any controllers solving the problem and let's use very large drives? I'm planning to buy a CMD CQD-220/TM for our Vaxstation for using with a Fujitsu 2266 or Wren VII. The Fujitsu is 29 K larger than Wren VII (formated capacity with 512K blocks) and is just over 1 Gbyte but the Wren is few K under the magical 1Gbyte level... -- Christer Olsson I MedNet I Phone: day: +46+31-853760 Kaggeledsgatan 11 I Medicinaregatan 7b I night: +46+31-843740 S-416 74 Gothenburg I S-400 33 Gothenburg I Email: co@adagio.fy.chalmers.se Sweden I Sweden I SUNET: MEDNT2::C_OLSSON