SEO

Hi,

I'm having trouble with my new motherboard, trying to setup
the onboard SATA RAID.

The MB is a Gigabyte GA-K8NXP-SLI -- a socket 939 with
nvidia nForce4 chipset. It comes with onboard nVidia
SATA RAID. Right after the BIOS setup, I enter the RAID
setup, and can create my array (RAID-0) of two drives.

But then, when I enter the installation program, the
thing doesn't see the array -- it sees the two drives
as if they were simply connected to non-RAID ports.

Is there a way around this? I was expecting the installer
to recognize this piece of hardware and proceed accordingly.

Any experience with this setup? Success stories?

Thanks!

Carlos
--

Carlos Moreno wrote:
> The MB is a Gigabyte GA-K8NXP-SLI -- a socket 939 with
> nvidia nForce4 chipset. It comes with onboard nVidia
> SATA RAID. Right after the BIOS setup, I enter the RAID
> setup, and can create my array (RAID-0) of two drives.
>
> But then, when I enter the installation program, the
> thing doesn't see the array -- it sees the two drives
> as if they were simply connected to non-RAID ports.

Right, that's exactly what you have in your system. You don't have a
hardware RAID controller:
http://linux.yyz.us/sata/faq-sata-raid.html

> Is there a way around this?

Forget the fake-RAID setup in BIOS and setup software RAID in the FC4
installer:
http://fedora.redhat.com/docs/fedora...isk-druid.html

--
Markku Kolkka
markku.kolkka@iki.fi

Markku Kolkka wrote:
> Carlos Moreno wrote:
>
>>The MB is a Gigabyte GA-K8NXP-SLI -- a socket 939 with
>>nvidia nForce4 chipset. It comes with onboard nVidia
>>SATA RAID. Right after the BIOS setup, I enter the RAID
>>setup, and can create my array (RAID-0) of two drives.
>>
>>But then, when I enter the installation program, the
>>thing doesn't see the array -- it sees the two drives
>>as if they were simply connected to non-RAID ports.
>
>
> Right, that's exactly what you have in your system. You don't have a
> hardware RAID controller:
> http://linux.yyz.us/sata/faq-sata-raid.html
>
>
>>Is there a way around this?
>
>
> Forget the fake-RAID setup in BIOS and setup software RAID in the FC4
> installer:
> http://fedora.redhat.com/docs/fedora...isk-druid.html

That's the way I have it for the time being. However, the
machine is a dual-boot with Windows 2000 (which unfortunately,
I *have* to use for certain tasks, about 20 to 30% of the
time), and I want to have RAID in there too.

However, if I go the software RAID way, then Windows 2000
requires the entire disks for itself -- they have to be set
as "Dynamic Disks", which means that the OS creates ONE
partition labeled as NTFS (one partition per drive, spanning
the whole drive), and then it handles everything that happens
inside that partition. As a result, Linux can't use any
space of those drives.

Is there more documentation on that DMRAID that they talk
about in the page you pointed me to? It sounds interesting,
but sounds complicated (well, more than complicated, sounds
like a hack -- perhaps it has to be, given the "hacky"
nature of this technological abortion that they call
"onboard RAID controller"?? :-))

Why can't they simply do something in which you simply
connect two drives to a piece of hardware, and that piece
of hardware is, from every and any conceivable point of
view, seen by the OS as *one* hard drive with twice the
speed and twice the capacity? (that is, for RAID-0)

Thanks!

Carlos
--

In message <Pi0gf.43$MU2.30909@wagner.videotron.net>
Carlos Moreno <moreno_at_mochima_dot_com@mailinator.com> wrote:

> Markku Kolkka wrote:
> > Carlos Moreno wrote:
> >
> >>The MB is a Gigabyte GA-K8NXP-SLI -- a socket 939 with
> >>nvidia nForce4 chipset. It comes with onboard nVidia
> >>SATA RAID. Right after the BIOS setup, I enter the RAID
> >>setup, and can create my array (RAID-0) of two drives.
> >>
> >>But then, when I enter the installation program, the
> >>thing doesn't see the array -- it sees the two drives
> >>as if they were simply connected to non-RAID ports.
> >
> >
> > Right, that's exactly what you have in your system. You don't have a
> > hardware RAID controller:
> > http://linux.yyz.us/sata/faq-sata-raid.html
> >
> >
> >>Is there a way around this?
> >
> >
> > Forget the fake-RAID setup in BIOS and setup software RAID in the FC4
> > installer:
> > http://fedora.redhat.com/docs/fedora...isk-druid.html
>
> That's the way I have it for the time being. However, the
> machine is a dual-boot with Windows 2000 (which unfortunately,
> I *have* to use for certain tasks, about 20 to 30% of the
> time), and I want to have RAID in there too.
>
> However, if I go the software RAID way, then Windows 2000
> requires the entire disks for itself -- they have to be set
> as "Dynamic Disks", which means that the OS creates ONE
> partition labeled as NTFS (one partition per drive, spanning
> the whole drive), and then it handles everything that happens
> inside that partition. As a result, Linux can't use any
> space of those drives.
>
> Is there more documentation on that DMRAID that they talk
> about in the page you pointed me to? It sounds interesting,
> but sounds complicated (well, more than complicated, sounds
> like a hack -- perhaps it has to be, given the "hacky"
> nature of this technological abortion that they call
> "onboard RAID controller"?? :-))
>
> Why can't they simply do something in which you simply
> connect two drives to a piece of hardware, and that piece
> of hardware is, from every and any conceivable point of
> view, seen by the OS as *one* hard drive with twice the
> speed and twice the capacity? (that is, for RAID-0)

You can. The problem is the price of that piece of hardware. For a start it
usually requires SCSI discs, which cost more (and last much longer than)
their IDE equivalents. The better RAID controllers are complete external
processors, which do all sorts of fancy stuff, then connect to your host
system either over SCSI or Ethernet, or even Fibrechannel.

You could easily end up with more CPU horsepower in the Raid controller than
in the host computer.

The big advantage of hardware Raid, of course, and as you've discovered, is
that it will work equally well with Windows and Linux, as it presents the
host with a single virtual device, which is just a lot of blocks. The host
then interprets the blocks using its own filesystem. It follows from that,
that the filesystem should be FAT32.

At the risk of preaching to the converted, you do realise that Raid-0
doubles the chance of a failure? If either disc has a problem the entire
Raid set is broken. You really want to add a third disc in a Raid 3/4
configuration (size = 2 x disc, the third is for redundancy), and get the
resilience that Raid was originally designed for.

>
> Thanks!
>
> Carlos
> --

--
Alan Adams
alan.adams@orchard-way.freeserve.co.uk
http://www.nckc.org.uk/

"Alan Adams" <alan.adams@orchard-way.freeserve.co.uk> wrote in message
news:98dcdacc4d.Alan.Adams@orchard-way.freeserve.co.uk...
> In message <Pi0gf.43$MU2.30909@wagner.videotron.net>

>> Why can't they simply do something in which you simply
>> connect two drives to a piece of hardware, and that piece
>> of hardware is, from every and any conceivable point of
>> view, seen by the OS as *one* hard drive with twice the
>> speed and twice the capacity? (that is, for RAID-0)
>
> You can. The problem is the price of that piece of hardware. For a start
> it
> usually requires SCSI discs, which cost more (and last much longer than)
> their IDE equivalents. The better RAID controllers are complete external
> processors, which do all sorts of fancy stuff, then connect to your host
> system either over SCSI or Ethernet, or even Fibrechannel.

Or SATA. There are also some interesting IDE RAID cards from 3Ware and
Adaptec, which may support real RAID operations and present the drives to
the client as a single SCSI-appearing drive, but they do cost more than
those poiece of half-a-neuron-shared-among-3-gerbils Promise or MegaRAID
controllers.

> The big advantage of hardware Raid, of course, and as you've discovered,
> is
> that it will work equally well with Windows and Linux, as it presents the
> host with a single virtual device, which is just a lot of blocks. The host
> then interprets the blocks using its own filesystem. It follows from that,
> that the filesystem should be FAT32.

And that's a huge advantage, along with its general performance improvement
for *REAL* RAID cards. The big difficulty with them is that to reconfigure
them, you have to reboot the machine, even if you're not re-configuring the
boot drive. This sort of whackiness, and the weird sets of "this RAID card
does these things, but won't do this thing if you have this other thing
configured, except if you have that third condition, but we don't mention
the lack anywhere in the docs" drives me bugfutz.

For example, even good commercial grade RAID controllers have a 2 Terabyte
limit on individual RAID set sizes, due to a 32-bit limitation in the
controllers. This is documented *nowhere*, but as soon as you slap 16x400
Gig drives on a single RAID controller, even with really high end
controllers, you have to split it into two sets of 8x400. Most folks won't
run into craziness like that, but guess who had to deal with it last year?

> At the risk of preaching to the converted, you do realise that Raid-0
> doubles the chance of a failure? If either disc has a problem the entire
> Raid set is broken. You really want to add a third disc in a Raid 3/4
> configuration (size = 2 x disc, the third is for redundancy), and get the
> resilience that Raid was originally designed for.

That's workable for small arrays. I myself prefer to simply not use RAID for
pairs of drives, and instead do a nightly snapshot of one drive to the
backup drive. Done properly with tools like rsync and rsnapshot, this allows
you to create daily/weekly/monthly snapshots in a surprisingly small amount
of spare disk, and avoid a lot of pain dealing with backup tapes. And you
can run the backup tape run against the mirror, instead of the primary
drive, and take the load right off that active partition, and with IDE/ATA
or with SATA drives, you can put the drives on different posts and avoid
some bandwidth issues. You're still limited by your CPU and your backplane,
but you can get your backup running at very close to the maximum bandwidth
of the drives themselves this way.

In message <RJKdnVs8J9ChKR3eRVn-jA@comcast.com>
"Nico Kadel-Garcia" <nkadel@comcast.net> wrote:

<huge snip>
>
> That's workable for small arrays. I myself prefer to simply not use RAID for
> pairs of drives, and instead do a nightly snapshot of one drive to the
> backup drive. Done properly with tools like rsync and rsnapshot, this allows
> you to create daily/weekly/monthly snapshots in a surprisingly small amount
> of spare disk, and avoid a lot of pain dealing with backup tapes. And you
> can run the backup tape run against the mirror, instead of the primary
> drive, and take the load right off that active partition, and with IDE/ATA
> or with SATA drives, you can put the drives on different posts and avoid
> some bandwidth issues. You're still limited by your CPU and your backplane,
> but you can get your backup running at very close to the maximum bandwidth
> of the drives themselves this way.
>
>

Agreed with all that. However I think the OP was wanting to add two drives
together for double the capacity (striping) not mirror them for 100%
redundancy. Striping is the one Raid option which doesn't improve
reliability, in fact it halves reliability.

Incidentally what is the maximum size of FAT32 disc - or virtual disc on a
Raid controller?

--
Alan Adams
alan.adams@orchard-way.freeserve.co.uk
http://www.nckc.org.uk/

"Alan Adams" <alan.adams@orchard-way.freeserve.co.uk> wrote in message
news:a53febcc4d.Alan.Adams@orchard-way.freeserve.co.uk...

> Agreed with all that. However I think the OP was wanting to add two drives
> together for double the capacity (striping) not mirror them for 100%
> redundancy. Striping is the one Raid option which doesn't improve
> reliability, in fact it halves reliability.

Well, yes. I was referring more to pairs of drives, and the common practice
of mirroring them which a lot of folks consider useful and I consider
painfully useless when the far more likely source of filesystem corruption
is user error, and having nightly snapshots is very easy insuarnce against
that.

> Incidentally what is the maximum size of FAT32 disc - or virtual disc on a
> Raid controller?

I'm not sure about the FAT32 limits, there's a page about this at
http://www.microsoft.com/resources/d...f_fls_pxjh.asp.

But the maximum individual partition size on a RAID controller that I've
seen was 2 Terabytes from a 32-bit controller mit. (2^32 * 512 bytes/block =
roughly 2 Terabytes)

After that, you have to do some sort of software RAID, of which there are
plenty.

Nico Kadel-Garcia wrote:

> Or SATA. There are also some interesting IDE RAID cards from 3Ware and
> Adaptec, which may support real RAID operations and present the drives to
> the client as a single SCSI-appearing drive, but they do cost more than
> those poiece of half-a-neuron-shared-among-3-gerbils Promise or MegaRAID
> controllers.

That word "may" is disconcerting.

I'm trying to put together an eight drive system. I looked at the 3ware
9550SX, but it looks like it's not supported out of the box by any current
Redhat (RHEL, CentOS, Fedora). I'm not sure how I'd install if all disks
are on the controller in that case.

There's supposed to be some "install disk", but how does that fit into my
DHCP/PXE/NFS (ie. diskless) install process?

Frankly, at this point I'd be happy with a pointer to a cheap controller
that can handle eight SATA drives w/o any fancy RAID stuff. I'll deal with
that in software if necessary.

Anyone have suggestions?

I'd also be willing to pay a little more for real hardware RAID5, but (1) I
want to know that it is real hardware RAID5 <grin> and (2) it does need to
work out of the box with a Redhat (or I need to have some way to install
onto it with my network install process, if such a thing is possible).

Thanks...

Andrew

"Andrew Gideon" <c172driver194@tagonline.com> wrote in message
news:10802854.sZrKETtN8B@no.to.be.used.news.int.ta gonline.com...
> Nico Kadel-Garcia wrote:
>
>> Or SATA. There are also some interesting IDE RAID cards from 3Ware and
>> Adaptec, which may support real RAID operations and present the drives to
>> the client as a single SCSI-appearing drive, but they do cost more than
>> those poiece of half-a-neuron-shared-among-3-gerbils Promise or MegaRAID
>> controllers.
>
> That word "may" is disconcerting.
>
> I'm trying to put together an eight drive system. I looked at the 3ware
> 9550SX, but it looks like it's not supported out of the box by any current
> Redhat (RHEL, CentOS, Fedora). I'm not sure how I'd install if all disks
> are on the controller in that case.
>
> There's supposed to be some "install disk", but how does that fit into my
> DHCP/PXE/NFS (ie. diskless) install process?

It can get interesting. You'd need to build an appropriately driver-loaded
kernel, and integrate *THAT* into your PXE and network installs. I've done
it with SuSE 9.x and the 9500 series cards, so I know it's feasible.

> Frankly, at this point I'd be happy with a pointer to a cheap controller
> that can handle eight SATA drives w/o any fancy RAID stuff. I'll deal
> with
> that in software if necessary.

There is no *cheap* controller that does this, except maybe Promise, and I
wouldn't wish those on an enemy. Would an Adaptec 2810SA do for you? I've
had good success with Adaptec cards of various sorts. They're not quite as
nifty as 3Ware, but they beat the hell out of the Promise barrel scrapings.