On Wed, Apr 30, 2014 at 01:27:47PM -0400, Nir Soffer wrote: > ----- Original Message ----- > > From: "Dan Kenigsberg" <[email protected]> > > To: "Saggi Mizrahi" <[email protected]>, [email protected] > > Cc: [email protected], "David Teigland" <[email protected]> > > 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.
Initially, I also suggested a design similar to fence_sanlock, which I described in the last two paragraphs of this email: https://lists.fedorahosted.org/pipermail/sanlock-devel/2014-February/000433.html One of the fundamental features of that design is that loss of storage causes a host to be reset/fenced, which is precisely what we want and require for fence_sanlock. However, this is *not* the behavior that vdsm/rhev want, as described by Nir in the last two paragraphs in this email: https://lists.fedorahosted.org/pipermail/sanlock-devel/2014-March/000436.html This is a fundamental difference in goals and makes a fence_sanlock-like approach unsuitable for this feature. Dave _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
