Date: Mon, 13 Dec 1999 11:38:14 +0100 From: "Oliver Blasnik" <ob@omnilink.net> To: <freebsd-scsi@FreeBSD.ORG>, "Mike Smith" <msmith@FreeBSD.ORG> Subject: Re: Again: CRD-Raid-Controller and FreeBSD 3.x Message-ID: <002a01bf4556$28f56ca0$da1940c2@omnilink.de> References: <199912131014.CAA21782@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote:
>> And this could not work as far these maximum of 32 commands is =
host-based, not lun-based.
>>That would depend on the configuration of the unit. It'd work well =
for=20
>>the single-drive case.
... which is unrealistic, the typical install is one boot- and one (or =
more) data-partition(s).
>Perhaps. Better fixed firmware than terrible performance.
Again, think realistic, "fixing" FreeBSD is a more on-time-solution than =
waiting for cmdtech to do an update.
>> > You might want to consider using a PCI:SCSI RAID controller like a =
Mylex=20
>> > DAC960 or AMI MegaRAID. The host:cache bandwidth is _much_ better =
on=20
>NT supports these controllers, as does Intel Solaris. They probably =
have=20
>drivers for the PCI Sparc systems as well.
And what about non-PCI-systems? Sorry, again, think realistic. The only =
"works identical on all systems"-solution is external. And I prefer =
using prooven adaptec-drivers than not-so-often-used others on my =
systems...
Btw, I do not recognise that 3.3-stable (and older releases are running =
here, up from 2.1.6) do have drivers for the controllers you mentioned.
>> You could set up two CRD's to the same
>> drive bay to enable renundancy and cut off this single point of =
failure.
>... if they worked properly. 8)
Worked fine with Solaris2.6, and if disabling tq is the only solution on =
multiple-os-at-the-same-raid, I will do that on controller-level.
>> Last but not least, if one machine burns down, just take a new =
hardware,
>> plug it onto the raid and switch it on - running and up again. Tell =
me how
>> to do that with your controllers :)
>Easy. They all save their config on the array as well as in NVRAM. =
With=20
>the newer models you could even pull the battery-backed RAM module off=20
>the burnt controller and save the cached write data as well.
You have to open both systems and change hardware. This is wasted time =
in my point of view as you don't have this in an emergency case.
Now, let us end this thread, it is going into an "my controller is =
better"-war, which lets me think downto the "old commodore- and =
atari-wars" long time ago. They ended up with no result, as this thread =
would. There are multiple possibilities for multiple requirements. =
Better focus on a solution and a better FreeBSD.
Cu, Oliver
--=20
__ OMNILINK Internet Service Center GmbH
/ \ Hahnstrasse 70, 60528 Frankfurt
__\ /_________ Tel.: (0 69)66 44 10 Fax: (0 69)66 44 11 99
O M N I L I N K http://www.omnilink.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002a01bf4556$28f56ca0$da1940c2>