On Mon, Apr 13, 2009 at 6:19 PM, Neil Brown <neilb@xxxxxxx> wrote: > Do you have anything else in the works that you want to be in > 3.0-final? > My pending list is now: > - some more ddf self-tests > - think about Doug's opinion on 'homehost' > - review and update man pages. > > which is unlikely to be all done this week, but maybe next week. > If you (or anyone else) has things that can be done in that time frame > and you want in 3.0-final, a heads-up would be appreciated. Two items, although (2) is definitely post 3.0-final material. 1/ Modify the output of brief_examine_super_imsm() to specify "auto=md" in cases where the kernel has extended block device numbers (is there anyway to detect this other than by kernel version?). Currently it is always "auto=mdp". 2/ Introduce the HBA configuration file option to specify raid domains and hotplug policies: HBA=<platform | sysfs device path> domain=<platform | container uuid> hotplug=<ignore | reattach | rebuild> enforce_ports=<yes | no | warn> ...where: "HBA" selects the I/O controller explicitly with a sysfs device path or auto-detected in the 'platform' case. "domain" selects which container disks attached to this controller belong. I currently can not think of a clean way to make this capability available to native-md-metadata arrays because the automatic hotplug handling would need to consider partitions. Maybe in the native case it can be limited it to 'whole disk' arrays, or just the 'reattach' case? "hotplug" sets the hotplug event policy: the difference between 'reattach' and 'rebuild' being that the drive must already be marked as a spare or former member and rebuild will additionally write a spare record to any new disks. "enforce_ports" sets the policy on what to do when domain members are found outside of the HBA path. Specifying 'yes' tells mdadm to treat disks outside of the HBA path as missing for create, assemble, and hotplug. 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
