> by the way, some of the changes in you of the patches you sent have not > been > included in any form. They include: > > - the getinfo_super_disks method. I couldn't see why you need this. > All the > info about the state of the arrays should already be available. > If there is something that you need that we don't have, please > explain and > we can see how best to add it back in. Marcin has already answered this but here is my explanation. Current test devstate[i]==0 is always true for container so any device seems a good candidate to move. To be able to identify members, failed devices and real spares we updated devstate for containers. To find members we can just check which disks are used in subarrays, but a failed disk is removed from subarray after a short while and as soon as it happens we are not able to see a difference between the failed disk and a spare unless we look at metadata. > - min_active_disk_size_in_array. I don't think the minimum current > size is > really a good guide. I've kept the code for letting the metadata > handler > check the size, but anything beyond that should be done with domains > I > think. > E.g have a domain '2G-or-greater' which is assigned to all 2G or > greater > devices. Then anything smaller will automatically be excluded from > arrays > with those devices. So if someone doesn't base domains on size they may have a small spare added to an array where it cannot be used. Min_active_disk_size was more than required for an array that didn't occupy the whole disk but at least it ensured that we are not throwing in something that wouldn't help. If we do this the array will remain degraded but will have spare - so Monitor may think it does not need more. For this reason we also checked the case when there was a spare in "to" container. If the spare was not suitable (size check here too) we would still look for a good one. And now back to assembly. There is still a segmentation fault when we try to assemble a subarray. Occurs when there is any config file and we run "mdadm -As" or "mdadm -Asc /etc/mdadm.conf". content is NULL when we try to compare uuid in line 413 in Assemble.c. We are going to prepare some tests to add to current suite so it will be easier to verify new patches. Regards Anna --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. z siedziba w Gdansku ul. Slowackiego 173 80-298 Gdansk Sad Rejonowy Gdansk Polnoc w Gdansku, VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, numer KRS 101882 NIP 957-07-52-316 Kapital zakladowy 200.000 zl This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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
