Scott Mitchell wrote:
Hi all,
I may be getting a new Dell PE1850 soon, to replace our ancient CVS server
(still running 4-STABLE). The new machine will ideally run 6.0 and have a
PERC4e/DC RAID card - the one with battery-backed cache. This is listed as
supported by amr(4), but I'm wondering how well it actually works in the
case of a disk failure. Will the driver tell me that disk has failed (a
syslog message would be enough) or will I have to make a daily trip into
the server room to check the front panel lights? Presumably it handles
hot-swapping a replacement drive OK?
I found some posts mentioning some management/monitoring tools for these
controllers that were allegedly available from the www.lsilogic.com
website, but I can't find anything on there for FreeBSD. Do the Linux
tools work?
FYI there also has been a big update to the amr driver which claims to
dramatically increase performance among other things, interestingly
enought it was augmented by Yahoo, I can only assume they are moving to
Dell, yahoo for me (and now you :).
The updates are still in -current but it will be MFC'ed into stable
sooner or later.
http://lists.freebsd.org/pipermail/cvs-src/2005-December/056814.html
Log:
Mega update to the LSI MegaRAID driver:
1. Implement a large set of ioctl shims so that the Linux management apps
from LSI will work. This includes infrastructure to support adding, deleting
and rescanning arrays at runtime. This is based on work from Doug Ambrosko,
heavily augmented by LSI and Yahoo.
2. Implement full 64-bit DMA support. Systems with more than 4GB of RAM
can now operate without the cost of bounce buffers. Cards that cannot do
64-bit DMA will automatically revert to using bounce buffers. This option
can be forced off by setting the 'hw.amr.force_sg32" tunable in the loader.
It should only be turned off for debugging purposes. This work was sponsored
by Yahoo.
3. Streamline the command delivery and interrupt handler paths after
much discussion with Dell and LSI. The logic now closely matches the
intended design, making it both more robust and much faster. Certain
i/o failures under heavy load should be fixed with this.
4. Optimize the locking. In the interrupt handler, the card can be checked
for completed commands without any locks held, due to the handler being
implicitely serialized and there being no need to look at any shared data.
Only grab the lock to return the command structure to the free pool. A
small optimization can still be made to collect all of the completions
together and then free them together under a single lock.
Items 3 and 4 significantly increase the performance of the driver. On an
LSI 320-2X card, transactions per second went from 13,000 to 31,000 in my
testing with these changes. However, these changes are still fairly
experimental and shouldn't be merged to 6.x until there is more testing.
Thanks to Doug Ambrosko, LSI, Dell, and Yahoo for contributing towards
this.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
