>>On Thu, Apr 8, 2010 at 7:48 AM, Hawrylewicz Czarnowski, Przemyslaw >><przemyslaw.hawrylewicz.czarnowski@xxxxxxxxx> wrote: >>> If config has list of devices associated with container and it comprises >>given spare drive, UUID is set apporopriately to this container. >>> It allows to assign spare with proper container according >>> to content in devices parameter in configuration file. >>> >> >>I guess it would be nice if a user could direct spares via the >>configuration file, but what gets honored in the future when this >>value conflicts with a container group id in the metadata? Especially > You are right, but at this moment it is *always* first container. This proposal gives a way how user can point out the right one. We are already fixing this problem in a more comprehensive way with the spare migration and DOMAIN code. This 'devices' option will be deprecated in short order, and its presence would just complicate the policy decisions. For example, what takes precedence the DOMAIN keyword, 'devices' list, or at a future date a spare pool id in the metadata? What would you rather write a DOMAIN line to specify the hardware port ranges or a 'devices' line to identify individual disk devices and update the configuration file on an ongoing basis? >>when the actual device associated with a given name /dev/sda changes >>from one boot to the next, potentially even across controllers, or the >>admin moves the drive and forgets to update the configuration file. > but it will need to rewrite this part of config to respect eg. /dev/disk/by-id patterns which are constant, which is far beyond this patch. ...but now you have hard coded something that would be better to float between containers on an automatic as needed basis. The only degree of freedom I see missing in the current proposals is to have the ability to disable spare migration to a given container. That may be some nice icing to allow some containers/arrays to have higher rebuild priority, but let's finish the cake first :-). -- 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
