From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Saggi Mizrahi" <smizrahi(a)redhat.com>, nsoffer(a)redhat.com
Cc: devel(a)ovirt.org, "David Teigland" <teigland(a)redhat.com>
Sent: Wednesday, April 16, 2014 10:33:39 AM
Subject: Re: Sanlock fencing reservations
On Wed, Feb 26, 2014 at 11:14:33AM -0500, Saggi Mizrahi wrote:
> I've recently been introduced to the this feature and I was wondering is
> this really
> the correct way to go for solving this particular problem.
>
> My main issue is with making two unrelated flow dependent.
> By pushing this into the existing sanlock data structures you limit
> yourself
> in the future from changing either to optimize or even solve problems for a
> single use case.
>
> Having an independent daemon to perform this task will give more room as to
> how to implement the feature.
Saggi, are you thinking about something similar to fence_sanlockd
http://linux.die.net/man/8/fence_sanlockd and its client fence_sanlock?
Using them, instead of reimplementing parts of them within Vdsm, seem
reasonable in first glance.
However
http://www.ovirt.org/Features/Sanlock_Fencing#Why_not_use_fence_sanlockd.3F
claim that it wastes 2G of storage and requires explicit master domain
upgrade.
Nir, could you explain why so much space is required by sanlockd? Can it
be configured to use smaller area?
According to fence_sanlock manual, each host get a resource on the shared
storage. Each sanlock resource is 1MB (sector size * max hosts). So to serve
2000 hosts we need 2G.
We can use less space if we want to support smaller number of hosts, but
we need a new domain format that include a new volume for the fencing.
Nir