Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: dan@breeze.bellcore.com (Daniel Strick)
Newsgroups: comp.sys.sun
Subject: Re: Large disks hazardous to your data? (sun-spots v10n56)
Keywords: Hardware
Message-ID: <2279@brchh104.bnr.ca>
Date: 2 Apr 91 15:00:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 61
Approved: Sun-Spots@rice.edu
X-Original-Date: Fri, 29 Mar 91 22:31:32 -0500
X-Refs:  Original: v10n56
X-Sun-Spots-Digest: Volume 10, Issue 71, message 8
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

This comment is in response to recent items in sun-spots digest about SCSI
disk drives larger than 1 GB.  The subject lines were:

    1.2gig Fujitsu M2266SA SCSI info                        (from v10n55)
    Re: 1.2gig Fujitsu M2266SA SCSI info [SGI correction]   (from v10n55)
    Large disks hazardous to your data?                     (from v10n56)

The issue is software support (device drivers) for SCSI disk drives with
more than 2^21 sectors.  Since under SunOS each sector is usually 512
bytes, the magic limit is 2^30 (i.e. 1,073,741,824) bytes which we
typically refer to as 1 gigabyte.  If we are in marketing, we typically
multiply our drive storage capacities in gigabytes by 1.074 and throw in
15%-20% formatting overhead to make our product look better.  Therefore
drives advertised as 1.2 GB or less are probably safe.

The hazard is that the SCSI disk driver in the operating system might
through ignorance use the old "group 0" six-byte SCSI read/write commands
to access disk blocks whose addresses will not fit into the old six-byte
commands.  You might not get any error messages from the driver.  It might
just quietly trash the file system and it might not do that immediately.
It might wait until you have loaded the disk with important data.

Since the problem is not immediately obvious, one must carefully test
unknown SCSI drivers for the hazard before file systems are loaded.  Since
the hazard is deadly, you can't trust just any flake submitting articles
to sun-spots digest or netnews.  You have to do the test yourself.  Since
each driver, release, and version of SunOS is potentially different, each
must be tested independently.  (I have heard a rumor that the new desktop
SPARCstation SCSI driver seems to do it right and the other SUN drivers do
it wrong.  I have not looked for myself.)  It would be nice if someone at
Sun Micro closely related to SCSI driver support would divulge some
reliable version of the truth.

This is not a new problem.  The 1986 ANSI SCSI standard (X3.131-1986)
defined the ten-byte "group 1" read/write commands (sometimes called
"extended" because they are from a certain optional extension to the
"mandatory" disk command set, not because they are larger or handle larger
disks).  Five years later, computer vendors are still delivering systems
that don't use the extended read/write commands.

A year ago I submitted the following to sun-spots digest (see v9n56):

>  Date:    Thu, 22 Feb 90 06:25:32 -0500
>  From:    dan@breeze.bellcore.com (Daniel Strick)
>  Subject: Re: Help! need large (>1Gb) SCSI drives (sun-spots digest v09n051)
>
>  You are about to descend into what may well become the most majestic can
>  of worms to be opened in SCSI history.  One gigabyte is the magic capacity
>  at which SCSI disk drives formatted with 512 byte sectors will overflow
>  the 21 bit disk address field in the traditional six-byte SCSI read/write
>  commands for direct access devices.  Many SCSI device drivers will not
>  automatically switch to the ten-byte commands with 32 bit address fields.
>  They will silently truncate ...
>
>    Have a nice day.

Except for a few people who sent me mail to tell me I must be wrong
because their Wren-VIIs worked ok, nobody seemed to care.  (I want to
remind them now, "I TOLD YOU SO!")

Dan Strick, aka dan@bellcore.com or bellcore!dan, (201)829-4624