> -----Original Message----- > From: Phillip Susi [mailto:psusi@xxxxxxxxxx] > Sent: Tuesday, January 15, 2013 3:57 PM > To: Patelczyk, Maciej > Cc: Tomczak, Marcin; neilb@xxxxxxx; linux-raid@xxxxxxxxxxxxxxx; Dorau, > Lukasz > Subject: Re: [PATCH] imsm: Forbid spanning between multiple > controllers. > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 1/15/2013 5:31 AM, Patelczyk, Maciej wrote: > > Hi Phillip, > > > > Mdadm does not care about the controller unless you created IMSM > > based RAID. Basically you can create that type of RAID *only* on > > Intel based platforms with OROM enabled. It's Intel solution, we > > support it and we maintain it. It's very specific type of metadata. > > We provide this functionality in Linux, Windows and OROM/uEFI. It > > must be compatible between all three environments. If you have dual > > boot machine you can safely boot into Windows and then into Linux > > and your RAID Volume will be in proper state. > > > Dmraid cannot boot from RAID Volume, OROM can boot from IMSM RAID > > Volume directly. You don't need separate partition, hard drive or > > anything else. If you run Intel platform you can boot directly > > from supported RAID Volume. This is because OROM supports it. > > Mdadm respects OROM restrictions when creating IMSM based RAIDs. > > I understand that you will not be able to boot directly from the array > without the OROM, but sometimes you just need to access your data any > way you can, and mdadm should not refuse to mount the array based on > the absence of the OROM. Think disaster recovery. You should always > be able to connect the disks to another machine that may not have an > Intel controller and rescue your data. > > Additionally the ability to create and use arrays without the OROM > allows for simulation and testing, which is something the mdadm test > suite should be doing. > I agree. That is why you have IMSM_NO_PLATFORM flag. Just do: $export IMSM_NO_PLATFORM=1 $mdadm ... And it should work as you mentioned. Right now this option is described in manual. > > Spanning in Linux is something obvious. I know that is simply > > works because of Linux architecture. However spanned RAID Volumes > > are not supported in OROM and in Windows. If you allowed for > > spanned RAID Volumes in Linux we open the Pandora's box. In the > > worst case you will lose you data when entering to OROM (OROM will > > see only one set of disks attached to one controller and can mark > > RAID Volume as Failed) or if you boot to Windows (Windows driver > > will see two failed RAID Volumes in the worst case). In other case > > you will have RAID Volume marked as Degraded and rebuild will > > start. And what if you create 'bootable' RAID Volume? Well you may > > not be able to boot from it when it's spanned. > > Warnings about potentially troublesome situations are good, but > outright refusal is not. Yes, I realize it would be a problem for > Windows due to the poor way the driver has to be implemented ( why > can't the OROM see other disks on other controllers? ), but sometimes > you don't care about that. For instance, if you are setting up the > array on one machine where you can not connect all of the drives to > the same controller ( and do not care about booting from the array on > this machine ), but you are planning on moving them to a machine where > they will be. This is just one example of many situations where you > need to be able to say "I know what I'm doing, go ahead anyway". > Of course I agree in general. This is standard Unix way to do it. I'm root and I take full responsibility. I think that IMSM_NO_PLATFORM should handle spanning too. I will discuss it internally. Errr..., "I know what I'm doing, go ahead anyway" - well not quite so... Do you really know the target platform OROM's capabilities? Do you? When creating or assembling IMSM RAID mdadm looks for OROM and tries to determine its capabilities. You can look at the code (like platform-intel.h). When you create RAID Volume directly on target machine you're safe. Mdadm will prevent you from creating OROM incompatible RAID. If you create the RAID Volume with IMSM_NO_PLAFTORM flag or with different OROM you may be in situation is which some capabilities in one OROM will not be present in other OROM and then RAID Volume will not be assembled. Target OROM may not support given RAID Level, Strip Size or some other capability. Yes I know that is not nice, but this is how it works. There are many platforms, some changed by Vendors and we don't control all of it. If you create RAID with IMSM_NO_PLATFORM it's even worse ;-) So it's not so obvious with this 'go ahead' method. Of course you can always run mdadm --detail-platform on target platform and check if you're creating OROM compatible RAID Volume. maciej ��.n��������+%������w��{.n�����{����w��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
