Hi Mike, Thanks for looking into this and commenting.
This seems like such a niche issue I think it isn't ever going to get traction.
I anticipate some implementation challenges so community participation will help. btrfs needs hot spare solution, which I am working on, and its better to have it soon especially for data center uses. btrfs is another VM in the system. Now there is more pressure to look at system-wide hot spare efficiency for systems with heterogeneous VMs. Its a kind of important that we provide a holistic hot spare solution to the end user. In the days when system used to have one type of VM in the system, its global hot spare was really a system-wide global hot spare as well. Now with more types of VMs in the system these global hot spare aren't truly global any more, from the customers point of view who would also be concerned about total cost-per-byte.
Having a common pool of hot spares doesn't buy you much if all the different volume managers were to experience a failure -- in that case the sharing actively works against you (if you've only accomodated for say 1 of the 3 different volume managers failing at any one time; but if you have provisioned for worst case of all solutions failing then what was the point of the exercise?).
Good point. But what you have mentioned is a solution problem. Currently we do have global hot spare with in a VM containing different Raid volumes, and your point will apply their as well. And we expect customer to configure it properly as per their business needs. With system wide hot spare module, it will help to have global hot spare really a global hot spare no matter of whats underlaying VM is. And the same global hot spare rule/algorithm will apply but across VMs and Raids with in the system. As usual customers will still have choice to assign dedicated hot spare for more critical VM-raids if needed. Thanks, Anand -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
