Ultra 10 and larger IDE Drive - SCSI
Rick
drive and 512 MB of RAM. Is there a maximum disksize that Solaris or the
Ultra 10 will support. I'm thinking of adding a 40 Meg (IDE) drive. Also,
what type of memory does this thing take. It currently has two chips of
128MB a piece. Does this system support any of the shelf SCSI adapters.
Thank you,
Rick
news.verizon.net
Thank you,
Rick
The Sun parts must be supported to upgrade any parts and ultra10 is
only ide no SCSI
allowed. Bear in mind that you just cant put any parts in a Sun box.
Rick
> In article <fLCL9.51507$a8.4...@news4.srv.hcvlny.cv.net>,
> Yes, there are restrictions. You didn't mention the version of Solaris
> you're running, which is critical. Solaris 8 10/01 (I think) and later
> supported IDE disks > 32GB. Prior to that, disk size was modulo 32GB
> (so you 40GB drive would show up as 8GB). Solaris 7 and earlier didn't
> support IDE drives > 8GB and there was no patch around this.
>
> If you have a version of Solaris that will support the IDE drive of that
> size, you shouldn't have any problems.
>
> Or you could install a PCI->SCSI card and not bother with IDE at all.
>
I'm running Solaris 9.
Thank you,
Rick
Mike Mann
wrote:
>> In article <fLCL9.51507$a8.4...@news4.srv.hcvlny.cv.net>,
>> Rick <rsha...@pharmanet.com> wrote:
>>
>>> I've acquired a used Ultra 10 333 Workstation that was loaded with a 9
>>> gig drive and 512 MB of RAM. Is there a maximum disksize that Solaris or
>>> the Ultra 10 will support. I'm thinking of adding a 40 Meg (IDE) drive.
>I'm running Solaris 9.
I have an 80 Gb IDE disk in an Ultra 10 running Solaris 9 and it
works fine.
Mike.
--
My "From:" address is unmunged, valid and works. Wow!
G. Low
replied that the U5/U10, like any IDE pc, would support up to
137gig...as it was more of a limitation on the IDE bios...!
Now, would a 200gig IDE drive work with one of those IDE to SCSI on a
Sun workstation equipped with a SCSI card? if so, which IDE to SCSI
brandnames work the best? =)
Cheers!
Georgie
ultra...@hotmail.com
>I remember asking this kinda question sometime back, and a kind heart
>replied that the U5/U10, like any IDE pc, would support up to
>137gig...as it was more of a limitation on the IDE bios...!
no, it is not a "BIOS" limitation. specifically because an Ultra 10
does not use a pc BIOS. the Ultra 10 hardware supports ATA-5 lba addressing.
to use disks larger than 128GB (137 "marketing" GB) you need ATA-6 lba
addressing which the built-in IDE controller of the Ultra 10 does not
support.
G. Low
Bruce Adler
<ultra...@hotmail.com> wrote in message news:20021117.1...@cable.prodigy.com...
> In <3DFFA032...@doramail.com> "G. Low" <sola...@doramail.com> writes:
> >I remember asking this kinda question sometime back, and a kind heart
> >replied that the U5/U10, like any IDE pc, would support up to
> >137gig...as it was more of a limitation on the IDE bios...!
>
> no, it is not a "BIOS" limitation. specifically because an Ultra 10
> does not use a pc BIOS. the Ultra 10 hardware supports ATA-5 lba addressing.
> to use disks larger than 128GB (137 "marketing" GB)
Actually, everyone except RAM vendors (and programmers) agree with the
ISO (or whoever it is that defines metric units) that 1 GB = 10**9,
not 2**30.
On all the disk drives I've seen, the de facto and de jure definitions
for MB and GB have been metric units for over a decade.
There's nothing useful to be gained by claiming it's a marketing ploy,
it's simply that that's the way the whole world has agreed to define
the standard metric system prefixes (i.e., kilo-, mega-, giga-, etc).
In other words, the cut-off point you need to look for when shopping
for a new drive is 137GB (not 128GB).
Regardless, it's probably a non-issue because the drive vendors seem to
have chosen 120GB and 160GB as the two available capacities closest to
the 137GB boundary.
Note: The real limit for ATA LBA addressing is 2**37 bytes, which is
approximately 137.4 * 10**9 bytes (137,438,953,472 bytes). It's calculated
by multiplying the fixed sector size (512 bytes == 2**9), and the LBA
limit (2**28).
> you need ATA-6 lba
> addressing which the built-in IDE controller of the Ultra 10 does not
> support.
Actually, it's called the "48-bit Address Feature" or "48-bit LBAs". If
you simply look for LBA support, you're going to get the wrong thing.
All ATA-6 compliant drives support the LBA feature (it's required),
but only some of them support the optional "48-bit LBA Feature" (which is
optional on all ATA-6 drives but required on any ATA-6 drive whose
capacity exceeds the 28-bit LBA limit).
Regardless, whether Ultra 5/10s can or can not support the 48-bit LBA
Feature has absolutely nothing to do with the host controller hardware!
AFAIK, adding 48-bit LBA support to an Ultra 5/10 should simply require
updated device drivers for the OS and boot PROM (OBP).
One of the primary objectives of the designers of the ATA-6 48-bit LBA
Feature was to increase the maximum capacity *without* requiring any sort
of host controller hardware changes, merely software changes. AFAIK, the
ATA-6 capacity increase works as claimed and should *not* require a new
host IDE controller hardare.
Also, in many cases, if you add an ATA drive (that's larger than 137GB) to
an older system (that doesn't support the 48-bit LBA Feature), the host OS
will usually simply clip the drive's capacity to the 137 GB limit and
safely ignore the rest of the drive. But that trick doesn't always work
and I have tested it on Solaris for either SPARC or x86 (because
there's no point in me wasting my own money on a drive that's too large
for my current OS, and expanding my filesystems when the drivers are updated
would be a major hassle).
If a 120GB drive works okay on an Ultra 5/10, then I strongly suspect
that a 160 GB ATA drive will work just fine on both Solaris SPARC (and
Solaris x86), but it will of course be clipped to 137GB. If someone wants
to give me a free drive, I'll be glad to install and test it on my x86
system (of course I get to keep the drive).
I understand (but haven't verified) that the Solaris 9EA x86 release
includes full support for 48-bit LBAs. I saw a report that says it seems
to work just fine (of course, to boot from 48-bit LBA drive you'll need
a rather recent motherboard, or need to flash an updated BIOS to your old
motherboard when and if the BIOS update is available from your motherboard
vendor).
I'm not a SPARC expert, but AFAIK, there's nothing to prevent Sun from
adding the exact same support to the SPARC version of the ATA disk drivers
(except that Sun doesn't yet sell ATA drives that large and therefore
Sun doesn't have any incentive to fix the drivers until they're ready to
start selling drives larger than 137GB. And, of course don't forget
that booting off a drive that's larger than 137GB will also require
patching the FCode driver in the OpenBoot prom (which complicates adding
48-bit LBA support on older SPARC systems). In order to avoid that
hassle I wouldn't be surprised if Sun says you can't boot from a drive
that requires the 48-bit LBA Feature (i.e., you can only use it as a
data drive).
So for full 48-bit LBA support on SPARC systems you need from Sun an
updated kernel driver and an updated OBP driver, and for x86 systems you
need to upgrade to Solaris 9 x86 to get the updated kernel and realmode
drivers (before you attempt to install Solaris 9 x86 on a 48-bit LBA drive,
you probably need to flash an updated BIOS to add 48-bit LBA booting
support).
Your existing built-in IDE controller on either SPARC or x86 should work
just fine because 48-bit LBA support is a software feature that's transparent
to the host's IDE controller hardware.
Erik Max Francis
> Actually, everyone except RAM vendors (and programmers) agree with the
> ISO (or whoever it is that defines metric units) that 1 GB = 10**9,
> not 2**30.
>
> On all the disk drives I've seen, the de facto and de jure definitions
> for MB and GB have been metric units for over a decade.
Indeed. Disk capacity and bandwidth usage (or rates) are usually
measured in SI prefixes; it's only memory that's commonly (albeit very
commonly) measured in binary prefixes.
There are proposed SI binary prefixes, but since most people feel they
have silly names they're unlikely to catch on:
http://www.alcyone.com/max/reference/physics/binary.html
> There's nothing useful to be gained by claiming it's a marketing ploy,
> ...
Indeed. It's hardly a marketing ploy; it's because the way memory is
made it makes more sense to talk about binary multiples. That isn't
true of disk capacity or bandwidth, so people generally don't use them.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I love Mickey Mouse more than any woman I've ever known.
\__/ Walt Disney
Kepler's laws / http://www.alcyone.com/max/physics/kepler/
A proof of Kepler's laws.
Pat Norton
>Actually, everyone except RAM vendors (and programmers) agree
>with the ISO (or whoever it is that defines metric units)
>that 1 GB = 10**9, not 2**30.
The official definitions are given by the BIPM:
www.bipm.org/enus/3_SI/si-prefixes.html
Dragan Cvetkovic
Interesting. Didn't know about zetta and yotta (just imagine 1ZB), zeppto
and yocto.
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer