Areca Disk Adapter Question
Karl Denninger
karl at denninger.net
Sun Dec 6 02:28:36 UTC 2009
Jeremy Chadwick wrote:
> On Sat, Dec 05, 2009 at 07:43:35PM -0600, Karl Denninger wrote:
>
>> To those who might have more experience with these boards than I do - is
>> there a way to have them re-read the bus and export anything new (or
>> remove anything "not new") from the driver configuration?
>>
>> I can't figure out a way to do it as of yet - the 3Ware drivers
>> automatically export new units without a reboot, but it appears the
>> system has to be downed and reset for configuration changes to show
>> "through" to FreeBSD on the Areca drivers.
>>
>
> This is probably a stupid question, but -- doesn't camcontrol(8) handle
> this? arcmsr(4) does rely on scbus(4) and CAM, so "camcontrol rescan"
> or "camcontrol reset" would be my first guesses.
>
Here's the problem as I've seen it so far.
I can create a new raid set and then use "camcontrol rescan" to pick it
up. So far so good - the device nodes show up in FreeBSD and all
appears well.
Now let's say I need to DISMOUNT a set (or a passthrough JBOD disk)
while the machine is running. I dismount the disk in FreeBSD - now what?
If I pull the drive without telling the controller first, I get the
"beep of death" from the adapter bleating about it. If I remove the
volume set or passthrough from the adapter first, that's fine - I can do
that (I have one of the boards with an ipKVM, although I can also get to
it via the command line tools, even if they are a bit arcane)
BUT BUT BUT - there is no way to clear the devices nodes from FreeBSD!
If I attempt a "camcontrol rescan all" after pulling a set the machine
instantly panics with uncompleted I/Os to the disks I did not tamper
with - whether I tell the adapter I did it first or not.
With the 3ware drivers this is propagated through properly. Not so with
the Areca drivers. This is a fairly major problem in that it appears
that anything you do that causes a "da" device served by these boards to
disappear causes an instant panic. While this is expected behavior if
the device is in active use, it really, really sucks if it's not, as it
makes it flatly impossible to, for example, pull a disk carrier that has
a big drive on it you just ran a dump to.
I was hoping I was missing something.... if not, I'm gonna be pretty
bummed out. These boards are insanely fast (350MB/sec sustained on a
Raid 1/0 array of 4 WD350GB disks as just one example!) but.....
-- Karl
More information about the freebsd-stable
mailing list