[Tfug] RAID containers

Dean Jones dean.jones at gmail.com
Tue May 12 11:29:03 MST 2009


Bexley Hall wrote:
> Hi,
> 
> I thought I would get clever and use one server to build RAID (5)
> containers to be used in an identical server.
> 
> Much to my chagrin, this didn't work out as intended! The second
> ("other") server complained that they were "foreign" containers and
> promptly began scrubbing.
> 
> <frown>
> 
> Of course, nothing was "lost" -- since I had just built them from
> scratch.  But, it has me wondering why the controller (low end Dell
> PERC 3>mumble>) would insist on unilaterally doing this "for me"?!
> I.e., I can't see why it *must* do this so assume it is just a 
> piss-poor implementation?
> 
> I would have assumed, recognizing the containers as foreign, that I
> would be *prompted* as to how to handle them -- instead of having the
> decision made *for* me!
> 
> So, is there some reason that containers (whether they are simple
> *volumes*, striped arrays or RAID5) should *not* be portable from one
> controller to another (identical)?
> 

You do not say what your connection method is to the host so maybe SCSI?

For FC and SAS connected arrays this behavior usually exists due to the
possibility of having the container connected to multiple hosts for
failover purposes.

If the first server failed you want the second host to check the status
of the RAID groups etc to make sure nothing horrible happened when the
other system died, then bring the arrays online (or bring them online
and then check).

It would be nice to be able to turn that behavior off of course but that
is up to your raid card.

My guess is that the RAID card drops a GUID or some such onto the RAID
array, so when another controller connects it says, 'Oh that isn't my
array!'

Personally I have moved away from hardware RAID controllers and onto ZFS
for my storage since so much (pain) can vary from controller to
controller.

Too bad the CDDL and GPL aren't compatible because it is quite amazing
and I would like to see ZFS in linux instead of LVM/MD etc.








More information about the tfug mailing list