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@xxxxxxxxxx> 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.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
