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?
I don't want to reach a situation where we need to change a sanlock struct
and not be able to do it as it makes problems with fencing flows.
I believe in the mantra that things should do one thing and do it well.
This feels like an ad-hoc solution to a very niche problem.
Further more, it kind of seems like a mailbox issue.
Leaving a fencing request is just a message. In the
future I can see it just being a suspend-to-disk request
so that you don't even have to fence the host in such cases.
The only reason I see people putting it to sanlock is
that it's a daemon that reads from disk and has does fencing.
I agree that in VDSMs current state putting this in the mailbox
is unreliable to say the least but it doesn't mean that we can't
have a small independent daemon to do the task until we get
messaging in VDSM to a stable state.
IMHO it's better than having it as and ad-hoc feature to sanlock.
A feature which we can't remove later as someone might depend on it.
A feature that might limit us or that we might even abandon once we
have more reliable disk based messaging in VDSM.