Also, if you were planning a RAID configuration for your target
boot device and had that set up it may not be recognized in some
cases.
Note by "target" boot device I'm not referring to TDM as
[specifically] a target boot device, but the device in general.
Building a boot RAID and trying to reapply it elsewhere can be
problematic. (One of which is an issue you allude to below, but
which is not an issue I'm speaking about since it shouldn't apply.)
As of AppleRAID V2 moving a RAID set between machines (or creating a
RAID set via TDM) should not be problem if you do it correctly.
There are at least a few ways to do correctly, the most important
thing is that mirrored disks have to be removed together, ie, you want
to avoid degrading the mirror.
1) shutdown both machines and move the drives over, then power back up
(safest)
2) unmount the mirrored RAID volume, then disconnect the drives within
the timeout (default is 30 seconds), connect the drives to the other
machine within timeout.
3) if the RAID volume is not mirrored, unmount and move drives. there
is no timeout.
The timeout is used to allow mirrors to come online degraded when one
or more the disks is missing or not responding but it also kicks in
when you start pulling disks from mirror that is unmounted. The timer
actually resets every time a new disk is found, so if you have mirror
with many drives you can keep plugging one in every 25 seconds and go
beyond the usual 30 seconds. If you are moving mirrored sides of an
XServe RAID array, I would go with shutting down the machine, then
shutting down both sides of RAID array, moving, powering up in
opposite order.
If the RAID set is also a boot volume, then moving will require more
steps. On either PPC or Intel machines you can boot from the install
media and then select the RAID volume as the boot device (this is the
recommend way and should always work). On Intel, you can also option
boot and select any of disks in the RAID set. If you option boot, you
still need to go into System Preferences -> Startup Disk and pick the
volume as your boot device. If you are lucky, you might be able to
get machine to boot on new RAID disks without option booting but there
will most likely be a long delay in booting so you still should use
Startup Disk to set it.
This is really not any different than the non-RAID case. If you swap
in a new bootable disk, the system will not know which partition to
boot from and it will have to scan the disk every time you boot until
it finds a bootable partition. In that case you also want to use
Startup Disk to select the partition to boot from.
The issues with creating RAID configurations using target disk mode
were caused by the RAID software relying on Open Firmware device
paths to find all the disks in a RAID set.
We're talking Mac Pro's here. If so it doesn't use Open Firmware, it
uses EFI (with BIOS support.)
I was trying to give some the history of why this did not always
work. Not everyone is using Mac Pro.
If you use a different machine with the disks attached in a
different manner (like firewire TDM) you end up with different OF
paths to the disks.
This is always to be expected because you get [potentially]
different device tree geometries at any reboot.
In fact, just moving the disks to another machine could also cause
this issue.
Yes, but this issue should not be causal since device tree names
routinely change on any given system between reboots. This is why
they should never relied on for identifying devices uniquely.
Device paths for disks shouldn't be changing between boots if there
are no config changes. In either the RAID or non-RAID case, the
system uses a path to find a boot partition.
If I remember right, just booting from install media was enough to
fix up the OF paths in either case.
More of a [likely] coincidence, though I don't know how it could
"know" what device tree entries should or shoudln't be and "fix"
them, but this is rather moot. And again, no OF on Intel.
In Tiger, the on-disk AppleRAID Open Firmware driver partition was
removed and the OF paths in RAID header were removed. In Tiger and
beyond, the booting was switched to use Boot!=Root on all platforms
(PPC and Intel). Boot!=Root uses UUIDs to allow the disks of a
RAID set to "find" each other.
Apple Software RAID v2 has always used UUIDs, AFAIK for final
determination of RAID set members, and is the recommended method for
specifying vdevs for RAID operations. If for some reason it didn't
at some point, let's just say I'm glad Apple fixed this woolly
thinking.
There are two levels of finding the RAID set members, before and after
the kernel is loaded. The kernel level has always used UUIDs. The
booting side has not.
So unless you are using Panther or earlier on PPC machine, this
should hopefully no longer be an issue.
(please file bugs if you can prove otherwise :-)
I believe your comment should be that this is/was "a" concern, not
all the potential pit-falls and problems that exist when moving RAID
volumes and member sets around on OS X. In practice it's not as
robust as it always should be, and perhaps your anecdote suggests
one reason why.
I am not currently aware of any issues with moving RAID sets between
machines.
-rick
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
