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

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

[Jan Kara]

  Hi,

  I'm replying somewhat late but when going through attend requests I was
wondering:

On Fri 16-01-15 15:44:52, Anand Jain wrote:
> 1.
>  Hot spare: is an important feature for the data centers. Hot spare
>  feature is common to MD, LVM and btrfs. And each of it locks in
>  resource to be used only at the event of failure. A system running more
>  than one type of VM like LVM and btrfs would end up having hot spares
>  assigned to each of the different VMs which looks system under
>  utilized.
> 
>  So to increase the utilization of disk hot spares with in the system,
>  a common kernel module with API could do a job better, with some
>  additional features.
> 
>  If needed I can provide a shot talk (just talk no slides) so to obtain
>  feedback and comments from the experts and have discussions.
  Do you have a concrete proposal or even patches for the module? Because I
guess the general idea is fine but the issue may be in how should we
exactly tie into LVM and btrfs. So without the details there won't be
much to discuss...

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

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

[Anand Jain]

Thanks for the reply.

  now based on your advise, if my participation is confirmed, by march,
  I would come up with a concrete proposal or an experimental code
  to share results at the conference if needed.

Thanks, Anand


On 01/27/2015 06:18 PM, Jan Kara wrote:
>    Hi,
>
>    I'm replying somewhat late but when going through attend requests I was
> wondering:
>
> On Fri 16-01-15 15:44:52, Anand Jain wrote:
>> 1.
>>   Hot spare: is an important feature for the data centers. Hot spare
>>   feature is common to MD, LVM and btrfs. And each of it locks in
>>   resource to be used only at the event of failure. A system running more
>>   than one type of VM like LVM and btrfs would end up having hot spares
>>   assigned to each of the different VMs which looks system under
>>   utilized.
>>
>>   So to increase the utilization of disk hot spares with in the system,
>>   a common kernel module with API could do a job better, with some
>>   additional features.
>>
>>   If needed I can provide a shot talk (just talk no slides) so to obtain
>>   feedback and comments from the experts and have discussions.
>    Do you have a concrete proposal or even patches for the module? Because I
> guess the general idea is fine but the issue may be in how should we
> exactly tie into LVM and btrfs. So without the details there won't be
> much to discuss...
>
> 									Honza
>

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

[Mike Snitzer]

On Wed, Jan 28 2015 at  5:45am -0500,
Anand Jain <anand.jain@oracle.com> wrote:

> 
> 
> Thanks for the reply.
> 
>  now based on your advise, if my participation is confirmed, by march,
>  I would come up with a concrete proposal or an experimental code
>  to share results at the conference if needed.

Maybe I'm misunderstanding the proposal but..

This seems like such a niche issue I think it isn't ever going to get
traction.  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?).

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

[Anand Jain]

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

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

[Mike Snitzer]

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.

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

[Anand Jain]

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.
>