SEO

Probably a simple one this,

I have a RAID 5 SAS array on a HP DL380G5 which shows in the HP
utility as being 237GB.

However, SCO using FDISK or divvy only shows ~14GB of disk, with no
more space left for partitions.


I did find an article to do with an updated wd driver, but only
mentioned the 14GB problem with IDE drives, do you think this patch
would work with SAS drives or could it be something else?

boogybaz@gmail.com wrote:

> Probably a simple one this,
>
> I have a RAID 5 SAS array on a HP DL380G5 which shows in the HP
> utility as being 237GB.
>
> However, SCO using FDISK or divvy only shows ~14GB of disk, with no
> more space left for partitions.

Is that using the "lsil" driver? Get the newest version of that driver
from LSI Logic. Earlier versions had a bug which caused the OS to see
the drive size wrap at every 64GiB line. I can't quite make sense of
14GB but I suspect this is the same problem.

If "237GB" means 237*1000*1000*1000, then that's 3.448803909 * 64GiB and
I'd expect OSR5 to see 28.72GiB. If it means 237*1024*1024*1024, I'd
expect OSR5 to see 45.00GiB.

> I did find an article to do with an updated wd driver, but only
> mentioned the 14GB problem with IDE drives, do you think this patch
> would work with SAS drives or could it be something else?

The updated "wd" driver itself only affects IDE drives. However, the
patch includes some utilities which also work better with larger drives.
All of that should be included in the latest OSR5 maintenance pack
(MP5), which I recommend you install.

Life will probably be easier if, before starting your new install, you
use the LSI tools to create a small (10GiB or so) + a large virtual
drive. Install OSR507 into the small drive, add MP5(*) and the newest
"lsil" driver, then add the 2nd drive, which should now be recognizable
at its full size. It is probably possible to install from scratch onto
the large drive, but doing so requires a lot more knowledge and
patience.
(*)You'll want to install any other OSR5 pieces before MP5. e.g. the
development system, SMP, etc. MP5 has updates for all the SCO-provided
OS components. If you install MP5 before those components you'll have
to figure out how to layer on their MP5 update pieces; if you install
the components before MP5, MP5 will automatically update them.
You might want SMP if you have a hyperthreaded or multi-core
processor, even if you don't have an OSR5 SMP license. SMP will light
up HT without a license; I don't know (and can't figure out from SCO's
current docs) whether it does the same for multi-core. It's sort of
implied but not stated explicitly.

>Bela<

On 13 Mar, 11:50, Baz <boogy...@gmail.com> wrote:
> Probably a simple one this,
>
> I have a RAID 5 SAS array on a HP DL380G5 which shows in the HP
> utility as being 237GB.
>
> However, SCO using FDISK or divvy only shows ~14GB of disk, with no
> more space left for partitions.
>
> I did find an article to do with an updated wd driver, but only
> mentioned the 14GB problem with IDE drives, do you think this patch
> would work with SAS drives or could it be something else?

Heh. Do what I do. Install an RHEL 5 or similar contemporary operating
system with VMware support, then run SCO OpenServer 5.0.x in a
virtualized operating system. Since a contemporary server is so much
more powerful than what such an old operating system is designed for,
the performance hit so far has not been significant.

Baz wrote:
> Probably a simple one this,
>
> I have a RAID 5 SAS array on a HP DL380G5 which shows in the HP
> utility as being 237GB.
>
> However, SCO using FDISK or divvy only shows ~14GB of disk, with no
> more space left for partitions.
>
>
> I did find an article to do with an updated wd driver, but only
> mentioned the 14GB problem with IDE drives, do you think this patch
> would work with SAS drives or could it be something else?
>

Hi.

We recently had a case with a customer of ours using an IBM Xseries 226 which
could only "see" a portion of a 73x3 in RAID 5 disk configuration.

The problem turned out to be an option in the BIOS (enabled by default) which
dealt with disks up to 2GB in size. By turning of this options, SCO OS 5.0.7
(no MP applied) was able to detect and use the whole disk space.

I do know IBM != HP but I think it's worth checking.

Best,
Rob

On 13 Mar, 21:33, Bela Lubkin <fi...@armory.com> wrote:
> boogy...@gmail.com wrote:
> > Probably a simple one this,
>
> > I have a RAID 5 SAS array on a HP DL380G5 which shows in the HP
> > utility as being 237GB.
>
> > However, SCO using FDISK or divvy only shows ~14GB of disk, with no
> > more space left for partitions.
>
> Is that using the "lsil" driver? Get the newest version of that driver
> from LSI Logic. Earlier versions had a bug which caused the OS to see
> the drive size wrap at every 64GiB line. I can't quite make sense of
> 14GB but I suspect this is the same problem.

I used the "hpsas" driver as recommended by HP as it is a Smartarray
P400

>
> If "237GB" means 237*1000*1000*1000, then that's 3.448803909 * 64GiB and
> I'd expect OSR5 to see 28.72GiB. If it means 237*1024*1024*1024, I'd
> expect OSR5 to see 45.00GiB.
>
> > I did find an article to do with an updated wd driver, but only
> > mentioned the 14GB problem with IDE drives, do you think this patch
> > would work with SAS drives or could it be something else?
>
> The updated "wd" driver itself only affects IDE drives. However, the
> patch includes some utilities which also work better with larger drives.
> All of that should be included in the latest OSR5 maintenance pack
> (MP5), which I recommend you

Already got OSR5 maint pack installed
>
> Life will probably be easier if, before starting your new install, you
> use the LSI tools to create a small (10GiB or so) + a large virtual
> drive. Install OSR507 into the small drive, add MP5(*) and the newest
> "lsil" driver, then add the 2nd drive, which should now be recognizable
> at its full size. It is probably possible to install from scratch onto
> the large drive, but doing so requires a lot more knowledge and
> patience.
> (*)You'll want to install any other OSR5 pieces before MP5. e.g. the
> development system, SMP, etc. MP5 has updates for all the SCO-provided
> OS components. If you install MP5 before those components you'll have
> to figure out how to layer on their MP5 update pieces; if you install
> the components before MP5, MP5 will automatically update them.
> You might want SMP if you have a hyperthreaded or multi-core
> processor, even if you don't have an OSR5 SMP license. SMP will light
> up HT without a license; I don't know (and can't figure out from SCO's
> current docs) whether it does the same for multi-core. It's sort of
> implied but not stated explicitly.
>
> >Bela<

So you are saying, install any additional drivers & packages, then
install the maintenance release?

On 14 Mar, 01:17, Nico Kadel-Garcia <nka...@gmail.com> wrote:
> On 13 Mar, 11:50, Baz <boogy...@gmail.com> wrote:
>
> > Probably a simple one this,
>
> > I have a RAID 5 SAS array on a HP DL380G5 which shows in the HP
> > utility as being 237GB.
>
> > However, SCO using FDISK or divvy only shows ~14GB of disk, with no
> > more space left for partitions.
>
> > I did find an article to do with an updated wd driver, but only
> > mentioned the 14GB problem with IDE drives, do you think this patch
> > would work with SAS drives or could it be something else?
>
> Heh. Do what I do. Install an RHEL 5 or similar contemporary operating
> system with VMware support, then run SCO OpenServer 5.0.x in a
> virtualized operating system. Since a contemporary server is so much
> more powerful than what such an old operating system is designed for,
> the performance hit so far has not been significant.

I can't, it isn't supported by the vendor :-(

On 13 Mar, 12:50, Baz <boogy...@gmail.com> wrote:
> Probably a simple one this,
>
> I have a RAID 5 SAS array on a HP DL380G5 which shows in the HP
> utility as being 237GB.
>
> However, SCO using FDISK or divvy only shows ~14GB of disk, with no
> more space left for partitions.
>
> I did find an article to do with an updated wd driver, but only
> mentioned the 14GB problem with IDE drives, do you think this patch
> would work with SAS drives or could it be something else?

Hmm, this is odd.

The TA at:

http://www.sco.com/ta/126819

suggests that you should, depending on the BTLD you are using
you should be able to see up to 539Gb in size.

You havent said what version of SCO you are using and what
BTLD you are using but I would recommend that you:

1) Make sure you have the latest BLTD
2) Make sure you have the latest Maintenance Pack installed
3) Check the notes in the CHWP at:

http://www.sco.com/chwp

for the model og HP Server you are installing

4) Follow the guide at:

http://www.sco.com/ta/119088

if it is OpenServer 5 you are installing or have installed on this
machine.

If none of the above helps then I would contact your SCO Support
provider
for further assistance.

John

On 14 Mar, 13:47, jbol...@sco.com wrote:
> On 13 Mar, 12:50, Baz <boogy...@gmail.com> wrote:
>
> > Probably a simple one this,
>
> > I have a RAID 5 SAS array on a HP DL380G5 which shows in the HP
> > utility as being 237GB.
>
> > However, SCO using FDISK or divvy only shows ~14GB of disk, with no
> > more space left for partitions.
>
> > I did find an article to do with an updated wd driver, but only
> > mentioned the 14GB problem with IDE drives, do you think this patch
> > would work with SAS drives or could it be something else?
>
> Hmm, this is odd.
>
> The TA at:
>
> http://www.sco.com/ta/126819
>
> suggests that you should, depending on the BTLD you are using
> you should be able to see up to 539Gb in size.
>
> You havent said what version of SCO you are using and what
> BTLD you are using but I would recommend that you:
>
> 1) Make sure you have the latest BLTD
> 2) Make sure you have the latest Maintenance Pack installed
> 3) Check the notes in the CHWP at:
>
> http://www.sco.com/chwp
>
> for the model og HP Server you are installing
>
> 4) Follow the guide at:
>
> http://www.sco.com/ta/119088
>
> if it is OpenServer 5 you are installing or have installed on this
> machine.
>
> If none of the above helps then I would contact your SCO Support
> provider
> for further assistance.
>
> John

Sorry, SCO version is 5.0.7, the BTLD's are the latest from HP

John Boland wrote:

> On 13 Mar, 12:50, Baz <boogy...@gmail.com> wrote:
> > Probably a simple one this,
> >
> > I have a RAID 5 SAS array on a HP DL380G5 which shows in the HP
> > utility as being 237GB.
> >
> > However, SCO using FDISK or divvy only shows ~14GB of disk, with no
> > more space left for partitions.
> >
> > I did find an article to do with an updated wd driver, but only
> > mentioned the 14GB problem with IDE drives, do you think this patch
> > would work with SAS drives or could it be something else?

> The TA at:
>
> http://www.sco.com/ta/126819
>
> suggests that you should, depending on the BTLD you are using
> you should be able to see up to 539Gb in size.

This TA is interesting to me, but I'll get back to that in a moment.
First, the original poster's problem:

I mentioned that there was a driver bug in old versions of one
particular driver ("lsil") which caused wraparound at 64GB. (To be
clear: that has been fixed in current versions.)

You're using "hpsas", which might (I'm not sure) be genetically related
to "lsil". Anyway, doesn't really matter, what I want to say is that
any driver can potentially have bugs like this.

Please boot the system into the state in which it sees the 237GB RAID
drive as 14GB. Post the "%disk" and "%Sdsk" lines from this boot. You
can do this using an OSR507 boot CD + the "hpsas" BTLD. Get as far
as the first interactive question, then hit Alt-F2 to switch to the
hardware recognition display. Write down the disk-related hardware info
and post it here (try to transcribe exactly).

I'm thinking we'll see something in the numbers that explains the
situation (and might point to a workaround).

Now, regarding TA 126819. It says:

" Most SCSI Drivers use 255 heads and 63 sectors/track for large disks.
" Multiplying all the maxima:
"
" 65535 * 255 * 63 * 512 bytes/sector
"
" gives a maximum disk size of 539043724800 bytes or about 539GB.
"
" The wd disk driver (BTLD) included in Supplement CD 5 has been tested
" with IDE disks up to 1Tb in size and theoretically can support IDE
" disks up to 2Tb in size.

This is interesting to me because I did the work to make this driver
support >539GB (502GiB) drives, but I did it totally in the dark --
there were no drives to test with. Now there are 1TB IDE drives and
apparently the driver has been tested up to that limit (should be with a
geometry of 255 heads, 127 sectors/track, up to 65535 cylinders -- max
size 1.086TB / 0.988TeB).

Unfortunately, all of the "1TB" drives on the market are following the
decimal standard, they provide 1,000,000,000,000 bytes or a shred
higher, equal to 0.909TeB. So there's still no way to really test the
driver in the range where it would start using 255 sectors/track.

All the kernel & utility paths that deal with geometry _should_ be able
to handle that, but I worry that I may have missed something. We'll
see... Or maybe we won't, has any company announced a >1TB IDE (SATA)
drive? Maybe the inherent limitations in IDE are such that we'll
finally have to move to SCSI-based specs (SAS).

>Bela<

Baz wrote:
> On 14 Mar, 01:17, Nico Kadel-Garcia <nka...@gmail.com> wrote:
>> On 13 Mar, 11:50, Baz <boogy...@gmail.com> wrote:
>>
>>> Probably a simple one this,
>>> I have a RAID 5 SAS array on a HP DL380G5 which shows in the HP
>>> utility as being 237GB.
>>> However, SCO using FDISK or divvy only shows ~14GB of disk, with no
>>> more space left for partitions.
>>> I did find an article to do with an updated wd driver, but only
>>> mentioned the 14GB problem with IDE drives, do you think this patch
>>> would work with SAS drives or could it be something else?
>> Heh. Do what I do. Install an RHEL 5 or similar contemporary operating
>> system with VMware support, then run SCO OpenServer 5.0.x in a
>> virtualized operating system. Since a contemporary server is so much
>> more powerful than what such an old operating system is designed for,
>> the performance hit so far has not been significant.
>
> I can't, it isn't supported by the vendor :-(

Do you have to *tell* the vendor?