Re: [ovirt-devel] Sanlock fencing reservations

----- Original Message ----- > From: "Dan Kenigsberg" <danken(a)redhat.com&gt; > To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt;, nsoffer(a)redhat.com > Cc: devel(a)ovirt.org, "David Teigland" <teigland(a)redhat.com&gt; > 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.