Original Questions:
> I am interested in using using SCSI drives (such as the Wren 8) that have a
> capacity > 1.2 GB on either a Sun 4/470 with a Ciprico Rimfire 3523 SCSI
> controller or on a SS2 with Sun's SCSI controller. Both systems would be
> running 4.1.1. I understood that there may be problems addressing and/or
> formatting a drive > 1.2 GB in size.
> 1. Will the Ciprico and Sun drivers correctly address the entire drive?
> Can I use the drive on either system as a single partition?
Responses indicated yes and definitely yes, as of 4.1.1.
> 2. Will the SunOS or Ciproco format programs correctly format and fix bad
> spots anywhere on the drive?
SunOS format: with a patch in 4.1.1b, yes; ciprico: don't know. See below.
See description and caveats below. One person reported that there is still
a problem with the SunOS driver.
> 3. A distributor of Wren 8 drives told me that the above issues have been
> addressed by a PROM change by Imprimis in the drives themselves. Can anyone
> shed any light on this?
No specific answers with respect to Wren 8 drives.
> 4. Any other problems that I should know about for either configuration?
------------------------------------------------------------------------
From: kevins@Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
JEEEZUS - I have sent this out 30 times in the last two month. Please
do summarize.
Previous to SunOS 4.1.1, the Command Descriptor Block used by the Sun
SCSI drivers only contained 21 bits of address (group 0 CDB) and truncated
requests above 2^21 (*512 == 1GB) to some lower address. I.e. > 2^21
sectors on a SCSI disk would not work when higher blocks started getting
touched.
In 4.1.1, read and write work correctly, but the interface used by format
(uscsi) still does the wrong thing.
Recently, Sun has come out with its own > 1GB disk, and made the driver
which fixes all of these problems part of a CD "feature" disk.
For SCSA (Sun Common SCSI Arch.) machines (like SPARC* systems) you should
be able to take this driver and retrofit it. One of the goals of SCSA was
binary compatibility, I would hope they have not changed goals that much since
I left.
I have not tested this latter fix (I have a version of sd.o done 1.5 years
ago for a customer) nor do I know Sun's position in the matter - but 4.1.1
will work for read/write, and this new driver should be somewhat portable.
------------------------------------------------------------------------
>From Earl Smith (earl@cs.columbia.edu)
There is a problem in the Sun driver. There are people out there who have
fixed the problem in their own drivers. If you want to buy a big drive
and also somebody else's driver, it should work. Sun has fixed the problem
for SPARCstations ONLY, not for servers. They thought they fixed the problem
for servers, but they were wrong. They still have a register that wraps
around. The bug has been reported to Sun officially. I expect to push them
sometime around late August to get the thing fixed, if they haven't gotten
it fixed by now. A call to my salesperson before I purchased a large drive
brought the respose that the problem had been fixed. That is an error. It
has been fixed for workstations only, I believe; that is, for one of their
two types of SCSI drivers. You might want to get on the list of people
reporting this bug, so you get notified by Sun when it gets fixed.
------------------------------------------------------------------------
From: "(Alain Brossard EPFL-SIC/SII)" <brossard@sasun1.epfl.ch>
(I have included Alain's entire comments here, since they may be useful to others.)
A couple of weeks ago, I asked the format.dat entry for a Wren VIII.
I didn't get any replies from this list except from one or two interested
parties. After some discussion with Sun and reading information from this
list and elsewhere, there seems to be a lot of misinformation around. Hopefully
this note will clear some of this.
> From: Kevin Sheehan {Consulting Poster Child} <kevin@sun.com@ronin.UUCP>
>
> The
> problem is that the SCSI Command Descriptor Block (CDB) has a number
> of formats - the group 0 format commonly used by most SCSI drivers
> only has 21 bits of address, and 8 bits of count. The older drivers
> didn't check the address being used, and would unfortunately truncate
> the address, so some low address block would be the target of a read
> or write command gone awry. (A side note - the count limitation was
> why trying to up what minphys allowed in a chunk would break. Writes
> or reads > 128K got truncated as well (2^8*512))
>
> Sooo, that's the bad news. The good news is that the 4.1.1 SCSA driver
> does not have this limitation - it will use group 1 (larger address and
> count fields) commands for large addresses on disk. One small gotcha
> is that this change works for read/write, but the mechanism that format
> employs still uses group 0 commands.
>
> You should be able to use the 4.1.1 SCSA driver on earlier SCSA
> machines in the short term (binary compatibility certainly worked for
> 4.1 and 4.0.3, and is one of the SCSA goals), and I have been told that
> Sun will be making a patched sd.o available "soon" that fixes the other
> limitations.
>
> synergy!kevin@Sun.COM
This means that only the following SCSI driver can access
more than one GByte:
4.1: only sun4c architecture (not tested by myself, just a rumor)
4.1.1: all architectures
But, the program format does more than read and write sectors and
this will cause you grief if you don't take care. Don't try formatting
more than 1GByte under 4.1; nor under 4.1.1 if you are using the sun4
architecture: I've tried this and format fails writing the backup label;
I assume that the same problem occurs for the sun3 and sun3x architecture.
Here is an example of format failing under sun4 - 4.1.1:
===================
3. sd6 at sw0 slave 24
sd6: <Wren VIII cyl 2105 alt 2 hd 15 sec 93>
Specify disk (enter its number): 3
selecting sd6: <Wren VIII>
Block 2937870 (2106/0/0), Fatal non-media error (illegal request)
Block 2937963 (2106/1/0), Fatal non-media error (illegal request)
[disk formatted, no defect list found]
partition> e
partition e - starting cyl 0, # blocks 0 (0/0/0)
Enter new starting cyl [0]: 100
Enter new # blocks [0, 0/0/0]: 1900/0/0
partition> label
Ready to label disk, continue? y
Block 2939173 (2106/14/1), Fatal non-media error (illegal request)
Warning: error writing backup label.
Block 2939175 (2106/14/3), Fatal non-media error (illegal request)
Warning: error writing backup label.
Block 2939177 (2106/14/5), Fatal non-media error (illegal request)
Warning: error writing backup label.
Block 2939179 (2106/14/7), Fatal non-media error (illegal request)
Warning: error writing backup label.
Block 2939181 (2106/14/9), Fatal non-media error (illegal request)
Warning: error writing backup label.
Label failed.
===================================
The driver for sun4c, 4.1.1, doesn't give any error but format won't
format correctly past 1GByte, it wraps around. This is especially dangerous
if you are repairing sectors. There is an unofficial patch from Sun, it has
been posted to this list by Kevin Sheehan {Consulting Poster Child}
<kevin@sun.com@ronin.UUCP>. Although he doesn't say so, his patch only
works on the sun4c architecture. For completness sake, I'm including it at
the end of this message.
So with the patch, big drives can be formated safely under
sun4c and can be used safely, but not repaired, under sun4c - 4.1,
sun4, sun3, and sun3x under 4.1.1.
Now the drive can be formatted, but the next step: newfs will
also cause you grief! There is an addressing limit:
newfs -i 10240 sd2a
write error: 2766284
wtfs: I/O error
That number 2766284 seems to represent an addressing limit of
newfs. What I did is redefined my partition until it satisfied newfs.
I end up losing 123 cylinders out of 2105 data cylinders but I do end up
having a nice big partition of 1,36 GBytes which isn't all that bad!
Under 4.1 (and 4.1.1), you can use the 1.0GByte entry in
/etc/format.dat to safely format your drive: that is why Sun put it there!
I've also heard of a 1,3GByte entry under 4.1.1, but it isn't in my
4.1.1, maybe 4.1.1B?
Wren VIII
I don't have a format.dat entry and I don't have the knowledge
to generate one. I started up with the physical data and used that.
Start format, select the drive, define the type to be other and enter
the following values:
data cylinders: 2105 (although you won't be able to use more than 1982
due to the above problem with newfs)
physical cylinders: 2107
# of sectors: 93
# of heads: 15
rpm: 3600 (default, whatever it is, I didn't have the real value)
Format the disk and then partition it.
The c partition should be from 0 to 2105/0/0, the highest cylinder
number that newfs will accept is 1982. So the highest partition shouldn't
go above cylinder 1982 (1982/0/0), you might try to had more blocks, but
I didn't bother. Then, label the disk and newfs it and you are on.
partition> pri
Current partition table (original sd6):
partition a - starting cyl 0, # blocks 2764890 (1982/0/0)
partition b - starting cyl 0, # blocks 0 (0/0/0)
partition c - starting cyl 0, # blocks 2936475 (2105/0/0)
Filesystem kbytes used avail capacity Mounted on
/dev/sd6a 1363579 9 1227212 0% /mnt/a
here is one format.dat entry, but it doesn't format to as
much:
> From: hoel@cec.mtu.edu (Jim Hoel)
>
> The following is the 'best' format info.
>
> disk_type = "Seagate ST41650N"\
> : ctrlr = MD21 \
> : trks_zone = 1 : asect = 1 \
> : ncyl = 2105 : acyl = 2 : pcyl = 2107 : nhead = 15 : nsect = 87 \
> : rpm = 3600 : bpt = 41301 : = 0xd4
>
> Hello, I thought I would send you one more message. If you use the
> parameters I sent you there will be no problems. Keep in mind that I am
> using Sun O.S. ver 4.1.1 Sun-4c, part number 700-2687-10 rev A. The
> equipment is a Sparcstation II with a wren VI and a wren VIII. If you
> experience ANY write errors it is because you are trying to use more
> sectors than what the disk can physically pack onto the platters. It is
> allowed to use less than the maximum because then you only lose disk
> space.
>
> Filesystem kbytes used avail capacity Mounted on
> /dev/sd3c 1290069 25339 1135723 2% /scratch
>
> As you see I end up with about 1.3 Gbytes after I newfs. I have chosen
> to not reduce the number of inodes at this time. ( default = 1 inode per 2kbytes )
> This takes up about 10% of the disk. I probably should have reduced the number
> of inodes as I am using this drive as one big scratch area. ( I have some data
> files in excess of 730 Mbytes. )
>
> Happy computing, Jim Hoel Systems Engineer
> Center For Experimental Computation
> hoel@cec.mtu.edu
>
Other info:
>
> ==============================================================================
> >From bwong Fri Apr 12 15:57:41 1991
> To: rdamond@sungva
> Subject: Re: Maximum disk capacity
>
> 2gb is supported; more than that requires extensions to the size of the
> file system (which is now a 32-bit integer), which won't happen until
> SVR4.
> ==============================================================================
> >From Mike.Persichetty Thu Apr 11 23:33:15 1991
>
> To: rdamond@sungva
> Subject: Re: Maximum disk capacity
>
> Drives larger than our maximum apparantely will cause nothing more
> than grief for your customers. Our current esp scsi driver doesn't
> know how to deal with these drives, and from what I have heard even
> when we do support such larger devices in the driver, customers
> will be out of luck because we use unique firmware in the drives.
> Rumor has it that the file system becomes corrupted on these
> larger drives.
>
> mp
> ==============================================================================
> Pour Info seulement.
> Le patch suivant n'est pas un patch officiel.....
>
> Responsible Manager: awd
> Description:
> The scsa sd driver cannot correctly scan past 1 GB to support
> the upcoming 1.4 GB SCSI disks when used under format.
> It works correctly for block, normal, and uscsi I/O.)
>
> The impact of this problem is that format will appear to run
> correctly. It will not can past 1 GB. However, normal vmunix
> peration is unimpaired so you can use these big drives.
>
> There is one problem...DO NOT REPAIR A BLOCK using format.
> then format writes the sun defect list back it will clobber
> any data in the lower 1 GB area of the disk.
> Work around:
> backup the g and h partitions before reassigning blocks on disks
> bigger than 1 GB and restore the partitions afterwards.
>
>
> The following shell script patches a 4.1.1 sd.o or a vmunix
> image to fix this problem:
For sun4c exclusively, A.B.
> 1045071:
> 1045071:#!/bin/sh
> 1045071:echo 'sd_maptouscsi+98?W a1366015
> 1045071:+?W ae940017
> 1045071:+?W 2800003
> 1045071:+?W e016c000
> 1045071:+?W a0142020
> 1045071:+?W e036c000
> 1045071:+?W 30800016' | adb -w $1
> 1045071:# End shell script
> 1045071:
> 1045071:This generates the code:
> 1045071:
> 1045071:_sd_maptouscsi+0x98: srl %i1, 0x15, %l0
> 1045071:_sd_maptouscsi+0x9c: orcc %l0, %l7, %l7
> 1045071:_sd_maptouscsi+0xa0: be _sd_maptouscsi + 0xac
> 1045071:_sd_maptouscsi+0xa4: lduh [%i3], %l0
> 1045071:_sd_maptouscsi+0xa8: or %l0, 0x20, %l0
> 1045071:_sd_maptouscsi+0xac: sth %l0, [%i3]
> 1045071:_sd_maptouscsi+0xb0: ba,a _sd_maptouscsi + 0x108
> 1045071:
> 1045071:Which, translated to C, is, effectively,
> 1045071: if (blkno >> 21) {
> 1045071: g1 = (not zero)
> 1045071: dcom->dkc_cmd |= SCMD_GROUPT1;
> 1045071: }
> 1045071:
> 1045071:This then replaces the normally unused code for debug printouts
> 1045071:
> 1045071: DPRINTF_IOCTL(devp, "special %s",
> 1045071: (dcom->dkc_cmd == SCMD_READ) ? "read" : "write");
> 1045071:==================================================
>
> 1045071: Public Summary:
> 1045071:The g and h partitions should be backed up before repairing blocks
> 1045071:on disks bigger than 1 GB when using format because data may
> 1045071:be inadvertantly corrupted when the Sun defect list is written
> 1045071:back (to the wrong) place on the disk.
> 1045071:
> 1045071:For disks smaller than 1 GB, this is not a problem.
>
> From: "Michael S. Maiten" <msm@energetic.com>
> A recent article in one of the more popular computer periodicals
> discussed the problems on Sun desktops using SCSI disks greater
> than 669 MB.
The limit is 1GBytes.
>
>
> The problem described is currently not a feature under
> SunOS 4.1.1, specifically the SunOS SCSI driver and format.dat.
> The SCSI driver has never officially passed Sun internal QA
> on the desktop using filesystems or partitions greater than
> 669 MB. If the disk becomes highly fragmented and/or full,
> the SCSI driver may rewrite new data on top of existing data.
Could this be true? That one I haven't heard before, I just
suspect your salesman doesn't really know what he is talking about
(at least based on his talking about 669 MByte vs 1GByte).
> The format utility has never passed Sun QA formating BIG disks.
True.
Alain Brossard, Ecole Polytechnique Federale de Lausanne,
SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse
brossard@sasun1.epfl.ch
----------------------------------------------------------------
Thanks to:
mis@seiden.com (Mark Seiden)
kevins@Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
"(Alain Brossard EPFL-SIC/SII)" <brossard@sasun1.epfl.ch>
birger@vest.sdata.no ( Birger Wathne)
----------------------------------------------------------------
Doug Neuhauser Seismographic Station
doug@perry.berkeley.edu ESB 475, UC Berkeley
Phone: 415-642-0931 Berkeley, CA 94720
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:20 CDT