> > > Hi, > > > > > > hi, > > > I've applied the first four in this series, but I don't like this > one. > > > > > > 1/ I don't think there is any need to impose this restriction when > > > assembling an array - only when creating a new volume in an > array. > > We want to support only as many volumes as OROM (platform) supports. > Disks with IMSM metadata may be carried from other systems. > > I don't think that makes sense. > > There are two important issues here. > > 1/ we don't want to make a change to an array which will make that > array > inaccessible to the OROM. > 2/ we don't want to make it difficult for users to get their data. > > > So any create or grow attempt which could lead to the OROM being unable > to access the array should be stopped (unless explicitly over-ridden). > > But any attempt to access data on any array (i.e. assemble an array) > should succeed no matter whether it is compatible with the OROM or not. > > So --create and --grow should check for platform compatibility. > --assemble should not. > > --examine and --detail should probably report if the array is > incompatible with the OROM. Yes, I think that it is enough to give the information about the OROM compatibility for a volume (bootable, and visible) in --examine and --detail. In that case we need to scan all disks attached to the controller of the disk in the volume to "--examine". > > > > > > > > > > 2/ The check_volumes_number approach feels clumsy ... there must be > a > > > a better way (Assuming it is needed at all). > > container_content handler is to check OROM capabilities and mark > > unsupported volumes with disable bits > > (array.state:MD_SB_BLOCK_CONTAINER_RESHAPE and MD_SB_BLOCK_VOLUME). > > The caller function shall interpret the bits and act accordingly to > the context (for instance block activation but display the volume > information). I think that this restriction falls into that area. > However, there are only a few situations when this info is really > needed ie. When volumes are activated in various ways. > > Therefore I thought it makes sense to pass the info if counting of > activate volumes is really needed. > > More straightforward option is to add another input parameters to > container_content and change it in numerous places. > > Do you prefer this way? Or add a specialized handler to count the > volumes when it is needed? > > Hmmm.. so the issue is that a single controller can have multiple > separate containers (families?) with their own metadata. > So a controller with 4 ports could have a 2-device container with a > RAID1 and a RAID0, and a separate 2-device container with just a > RAID10. > > And maybe the controller has a limit of 3 arrays, so adding another > array to the second pair would be an error. A single family (container) can have up to 2 volumes. The limit of number of volumes is per controller. It does not matter how they are split among families. > > Is that the right sort of scenario? Yes. > > So when assembling the second container we don't need to look at the > first one, but when adding an array to the second, we do need to look > at the first one. I think we always need to count all volumes to be sure that activated or created volume is OROM compatible. This is exactly the same as in creation. When a volume is created on sda, sdb and sdc, we take take the first disk controller (because all disks must share the same controller) and count the volumes on all disks attached to the controller. Marcin Labun -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
