On 2007-04-10T07:09:44, Alan Robertson <[EMAIL PROTECTED]> wrote:
> > As even calling crm_master and having it do a compare and
> > update-if-modified, or filtering it in the CIB directly requires to at
> > least contact and query the CIB, I'd probably still track the state in
> > the RA somewhere. (As to avoid forking and IPC.)
> Keeping track of it in the RA would typically involve extra forking to
> do the query, and comparision, and also to manage the state in tmp
> files, etc.
Uhm. Forking?
echo, read, and even sourcing the file (if it's written in VAR=VALUE
style) doesn't incur that overhead.
Anyway, Andrew fixed it in the CIB by now, so this part of the
discussion is mood ;-)
> > Or even better, monitoring drbd via a daemon which sends an async
> > notification (either a crm_master change or a async failure
> > notification) when something happens, instead of polling via the LRM.
> >
> > I'd wish to have a "fast" LRM interface, where the instantiation of a
> > resource starts a sub-daemon to control it and then manage it via IPC
> > (or maybe stdin/stdout) with that process - and, if the daemon support
> > it, have it do async monitoring as well.
>
> Invoking the LRM to update the CIB isn't more efficient than just
> updating the CIB.
That is not what this suggestion is about. Try reparsing it ;-)
Such a daemon would obviously easily keep internal state and only issue
CIB updates or async (failure) notifications as needed. It'd avoid a lot
of forking for various operations.
Sincerely,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
