Hi,
On Wed, Sep 16, 2009 at 02:08:06PM +0200, Florian Haas wrote:
> On 2009-09-16 13:29, Dejan Muhamedagic wrote:
> > Hi Florian,
> >
> > On Wed, Sep 16, 2009 at 08:25:30AM +0200, Florian Haas wrote:
> >> Lars, Dejan,
> >>
> >> as discussed on #linux-ha yesterday, I've pushed a small changeset to
> >> the Filesystem RA that implements a monitor operation which checks
> >> whether I/O on the mounted filesystem is in fact possible. Any
> >> suggestions for improvement would be most welcome.
> >
> > IMO, the monitor operation is now difficult to understand. I
> > don't mean the code, I didn't take a look at the code yet, but
> > the usage. Also, as soon as you set the statusfile_prefix
> > parameter, the 0 depth monitor changes behaviour. I don't find
> > that good. The basic monitor operation should remain the same and
> > just test if the filesystem is mounted as it always used to.
>
> I thought it was fairly straightforward the way it's implemented, but
> then of course I'm no impartial judge. :) I can change it so that if
> depth=0 (the default), and statusfile_prefix is set, then
> statusfile_prefix is effectively ignored. Which I believe isn't
> intuitive. And it would also mean that "depth" (i.e. $OCF_CHECK_LEVEL)
> suddenly affects start and stop, which isn't exactly straightforward either.
The statusfile_prefix parameter should not affect the basic
monitor operation. I think that if it does that will be source of
confusion.
> > The new parameter should influence only the monitor operations of
> > higher (deeper :) depth. So, I'd propose to have two depths, say
> > 10 and 20, of which the first would be just the read test and the
> > second read-write.
>
> Is there any convention on what granularity "depth" uses? The other RAs
> that use it (IPaddr and mysql, AFAICT) only distinguish between zero and
> nonzero.
Not sure, but I don't think so. I think it's up to the RA to
interpret it at will. At any rate, multiple depths may be
supported.
> > Finally, the statusfile_prefix should be optional for deeper
> > monitor operations and default to .${OCF_RESOURCE_INSTANCE}. If
> > OCF_RESOURCE_INSTANCE doesn't contain the clone instance, then we
> > should append the clone instance number (I suppose that it's
> > available somewhere).
>
> It does. I just thought it would be helpful to see the node name in there.
You can then set the default to: .`uname`.${OCF_RESOURCE_INSTANCE}.
I think it's good that it starts with '.' because it's of no
importance to the normal users. Perhaps we could also reserve a
directory named say .OCF_Filesystem_monitor/. I doubt that that
name would collide with normal users.
> And, I deliberately used an empty default to employ my "omit monitoring
> in case statusfile_prefix is unset" logic. Which has its pros and cons,
> as stated above.
>
> I'm not at all unwilling to change the agent if others agree that your
> suggestions should be implemented, but I'd like to hear some more thoughts.
I'm willing to hear other comments, of course, but please note
that this is not about democracy :)
Cheers,
Dejan
> Cheers,
> Florian
>
> _______________________________________________________
> Linux-HA-Dev: [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
