On Thu, Aug 6, 2009 at 9:02 PM, Neil Brown<neilb@xxxxxxx> wrote: > On Tuesday August 4, dan.j.williams@xxxxxxxxx wrote: >> The following changes since commit fa09d4961e5c72da3c7f78d53a7d64f5196110a3: >> NeilBrown (1): >> Examine: fix --examine --brief --verbose on containers. >> >> are available in the git repository at: >> >> git://github.com/djbw/mdadm.git master >> >> Dan Williams (10): >> teach imsm and ddf what st->subarray means at load_super time >> fix RebuildMap() to retrieve 'subarray' info > > Thanks. I've pulled and pushed them all, but I'm not quite sure of > this one. > What metadata information do we want to have in the map file? > The main use of the map file is for incremental assembly. When we > find a device, the map file tells us which array/container to attach > the device to. > So subarrays probably aren't important in the map file and maybe > shouldn't be stored there at all??? > > What was the context where the current behaviour became an issue? This was noticed when debugging why udev sometimes did not create a device node for an imsm container. The fix for that was to update the container UUID after adding a subarray. It was during this debug that I noticed that -Ir would not recreate the same map file as -C, so I fixed it for consistency. Now that I look, we are currently using the mapfile to look up the user-friendly device name for "--detail --export". So it is currently needed until we can transition to the named device support you added in 2.6.29. >> >> Hi Neil, >> >> This is the same queue that was sent previously [1], but with a few >> additions: > > Sorry I didn't respond to that - late June was a bad time for me :-( Not a problem. >> >> >> Lastly, I notice that there is a regression of sorts since commit >> fa09d496 "Examine: fix --examine --brief --verbose on containers". >> Changing the order of containers and members confuses mdadm -Asc, or -As >> when /etc/mdadm.conf is present. We now only get the container, and no >> members in the multiple container case. Unintended consequence? > > Certainly unintended. I guess I had forgotten that the order of > things in mdadm.conf is important. > Maybe the best approach would be for Examine.c to call in to the > metadata handler a second time to get the subarrays. > > What would you think of something like the following? Works for me, and you already committed it because I was too slow to respond, sorry about that. Thanks, Dan -- 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
