Re: [LSF/MM ATTEND]: Hot spare module ? And Btrfs volume management without mount

[Anand Jain <Anand.Jain@oracle.com>]

Thanks Mike for the comments.
- Anand

On 01/29/2015 09:59 PM, Mike Snitzer wrote:
> On Thu, Jan 29 2015 at  3:31P -0500,
> Anand Jain <Anand.Jain@oracle.com> wrote:
>
>>
>> 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.
>
> So the btrfs hot-spare needs to be implemented in btrfs.  But any layer
> that needs to manage lvm2, btrfs and MD raid should be implemented in
> userspace, e.g. in SSM, see: http://sourceforge.net/projects/storagemanager/
>
> Though if you truly want the all volume managers to have immediate
> access to this global spare for failed member replacement from the
> kernel's failure paths across all volume managers.. that gets more
> complicated (so that must be what you're talking about).
>
> This just feels like a "nice to have" that I'm not hearing anyone
> asking for... but I could just be sheltered.
>
> Now that LVM can manage/use MD volumes we already have a common
> interface for managing lvm2 and MD. btrfs isn't something lvm2 would
> naturally take on supporting though.
>