Mailing List Archive: Linux-HA: Dev

Monitor operation for the Filesystem RA

Index | Next | Previous | View Threaded

florian.haas at linbit

Sep 15, 2009, 11:25 PM

Post #1 of 17 (3340 views)
Permalink

Monitor operation for the Filesystem RA

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.

Do I win the prize for the longest changeset description or what? ;)

Cheers,
Florian

Attachments:

signature.asc (0.25 KB)

dejanmm at fastmail

Sep 16, 2009, 4:29 AM

Post #2 of 17 (3205 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

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.

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.

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).

I hope that this way the usage would be more straightforward. At
least it looks so to me.

> Do I win the prize for the longest changeset description or what? ;)

We need good documentation. I think it's great to write such
descriptions :)

Cheers,

Dejan

> Cheers,
> Florian
>
>

> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

florian.haas at linbit

Sep 16, 2009, 5:08 AM

Post #3 of 17 (3206 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

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 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.

> 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.

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.

Cheers,
Florian

Attachments:

signature.asc (0.25 KB)

dejanmm at fastmail

Sep 16, 2009, 5:41 AM

Post #4 of 17 (3211 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

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: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dk at in-telegence

Sep 16, 2009, 5:44 AM

Post #5 of 17 (3212 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

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 agree.

> 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.

Why not 1 and 2?

Then we'd have
0 = old behaviour
1 = read
2 = read/write

> 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).

As fgh said, when you want to monitor a readonly fs, you'd have to know
the clone instance number for creating the file to read from. Not a good
idea imho. Or you'll have several files around which would be even more
ugly when you think about a larger cluster.

Why do we have to make the name configurable at all? Why not just give
it a generic name and only let the user configure OCF_CHECK_LEVEL for
each monitor? That said, I have not dealt with cluster filesystems yet.
Was the hostname-idea to avoid having multiple monitor instances trying
to write to one file and maybe run into locking/timeout issues?

Regards
Dominik

> I hope that this way the usage would be more straightforward. At
> least it looks so to me.
>
>> Do I win the prize for the longest changeset description or what? ;)
>
> We need good documentation. I think it's great to write such
> descriptions :)
>
> Cheers,
>
> Dejan
>
>> Cheers,
>> Florian
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejanmm at fastmail

Sep 16, 2009, 5:56 AM

Post #6 of 17 (3233 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

Hi,

On Wed, Sep 16, 2009 at 02:44:13PM +0200, Dominik Klein wrote:
> 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 agree.
>
> > 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.
>
> Why not 1 and 2?
>
> Then we'd have
> 0 = old behaviour
> 1 = read
> 2 = read/write

Nothing against it, but it would be good to leave some space in
between to let some air in :) Seriously, who knows, one may some
day implement a sort of half-read-write check which could fit in
between 1 and 2 and then we would be out of good numbers :)

> > 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).
>
> As fgh said, when you want to monitor a readonly fs, you'd have to know
> the clone instance number for creating the file to read from. Not a good
> idea imho. Or you'll have several files around which would be even more
> ugly when you think about a larger cluster.
>
> Why do we have to make the name configurable at all? Why not just give
> it a generic name and only let the user configure OCF_CHECK_LEVEL for
> each monitor?

I'd agree with that too. Basically, we should be able to figure
out a unique name for the test file. The user gains absolutely
nothing by defining that optional parameter, i.e. there is no
extra functionality in that.

> That said, I have not dealt with cluster filesystems yet.
> Was the hostname-idea to avoid having multiple monitor instances trying
> to write to one file and maybe run into locking/timeout issues?

Yes, for NFS or OCFS2. But that should be covered by combining
the hostname with the instance name. To avoid the root directory
mess, I'd also suggest to create all test files in one
subdirectory.

Cheers,

Dejan

> Regards
> Dominik
>
> > I hope that this way the usage would be more straightforward. At
> > least it looks so to me.
> >
> >> Do I win the prize for the longest changeset description or what? ;)
> >
> > We need good documentation. I think it's great to write such
> > descriptions :)
> >
> > Cheers,
> >
> > Dejan
> >
> >> Cheers,
> >> Florian
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

lmb at suse

Sep 16, 2009, 9:11 AM

Post #7 of 17 (3209 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

On 2009-09-16T14:41:35, Dejan Muhamedagic <dejanmm [at] fastmail> wrote:

> The statusfile_prefix parameter should not affect the basic
> monitor operation. I think that if it does that will be source of
> confusion.

I don't think it will cause confusion, but it would make the "old"
behaviour unavailable; that isn't good, so depth=0 should remain as it
is today.

In particular, the initial probe shouldn't do this, I think; for that,
the depth=0 as of today is fully sufficient.

> 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.

Yes, it's not defined anywhere.

> > 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}.

That isn't a good default. It'd end up cluttering the fs eventually, as
nothing exists to clean it up.

> 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.

I'd suggest that most users would add a directory name to their prefix,
yes.

Unless we want them to enter special characters and 'eval' the
string in the RA, I suggest we only allow them to set the prefix, and
append `uname -n`.{instance}.{clone_no} to it.

A good read-only test that doesn't cause any files to show up is to stat
the mountpoint; that may be a good level 10. Combining all ideas
together, I end up with ...

0 As today
10 stat()
20 read file
30 create-delete file
40 create-write-read-delete file

I'd suggest conv=fdatasync/fsync instead of flag=direct.

Which should really allow everyone to be happy (perhaps 30 isn't
needed).

They could be numbered 0,1,2,3,4 of course, but I'd like to leave some
space in-between for adding features.

Regards,
Lars

--
Architect Storage/HA, OPS Engineering, Novell, Inc.
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 [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

lmb at suse

Sep 16, 2009, 9:14 AM

Post #8 of 17 (3204 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

On 2009-09-16T14:56:40, Dejan Muhamedagic <dejanmm [at] fastmail> wrote:

> Yes, for NFS or OCFS2. But that should be covered by combining
> the hostname with the instance name. To avoid the root directory
> mess, I'd also suggest to create all test files in one
> subdirectory.

The admin may have a valid reason for specifying the prefix (if they
don't want the subdirectory in the root, for example).

They get to specify the prefix, from which we construct the final string
by adding the instance/host/clone# number, and using that relative to
the mountpoint.

Quite simple, really. ;-)

BTW, while we're at it - bonus points for implementing a
clone-filesystem check which _tries to read from the other node's files_
and fails if the data is found to be sufficiently outdated when it
shouldn't. But just maybe I'm going over the top here.

It's amazing how much time can be spent painting bikesheds.

Regards,
Lars

--
Architect Storage/HA, OPS Engineering, Novell, Inc.
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 [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

florian.haas at linbit

Sep 16, 2009, 9:53 AM

Post #9 of 17 (3220 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

On 2009-09-16 18:11, Lars Marowsky-Bree wrote:
>> 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.
>
> Yes, it's not defined anywhere.

Thought so. :)

>>> 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}.
>
> That isn't a good default. It'd end up cluttering the fs eventually, as
> nothing exists to clean it up.

Really?
http://hg.linux-ha.org/agents/file/f8bc24bc1db4/heartbeat/Filesystem#l671

> I'd suggest conv=fdatasync/fsync instead of flag=direct.

The other Lars suggested that as well. :) But what about reads? Is there
any filesystem-agnostic way of saying "I want to read what's on disk,
rather than in cache" that's actually _better_ than opening the file
with O_DIRECT (realizing that it's a no-op for some filesystems)?

Cheers,
Florian

Attachments:

signature.asc (0.25 KB)

dejanmm at fastmail

Sep 16, 2009, 10:44 AM

Post #10 of 17 (3179 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

On Wed, Sep 16, 2009 at 06:14:13PM +0200, Lars Marowsky-Bree wrote:
> On 2009-09-16T14:56:40, Dejan Muhamedagic <dejanmm [at] fastmail> wrote:
>
> > Yes, for NFS or OCFS2. But that should be covered by combining
> > the hostname with the instance name. To avoid the root directory
> > mess, I'd also suggest to create all test files in one
> > subdirectory.
>
> The admin may have a valid reason for specifying the prefix (if they
> don't want the subdirectory in the root, for example).
>
> They get to specify the prefix, from which we construct the final string
> by adding the instance/host/clone# number, and using that relative to
> the mountpoint.
>
> Quite simple, really. ;-)

Makes sense. I'd just like to avoid that the parameter is
required to run monitor operation.

> BTW, while we're at it - bonus points for implementing a
> clone-filesystem check which _tries to read from the other node's files_
> and fails if the data is found to be sufficiently outdated when it
> shouldn't. But just maybe I'm going over the top here.

Do you mean that in that case all clones should fail? Can you
provide a use example.

> It's amazing how much time can be spent painting bikesheds.

I really don't find this discussion superfluous. In particular
given our record on user-friendliness.

Thanks,

Dejan

>
>
> Regards,
> Lars
>
> --
> Architect Storage/HA, OPS Engineering, Novell, Inc.
> 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 [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

lmb at suse

Sep 16, 2009, 11:44 AM

Post #11 of 17 (3202 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

On 2009-09-16T18:53:45, Florian Haas <florian.haas [at] linbit> wrote:

> > That isn't a good default. It'd end up cluttering the fs eventually, as
> > nothing exists to clean it up.
> Really?
> http://hg.linux-ha.org/agents/file/f8bc24bc1db4/heartbeat/Filesystem#l671

On a clean stop, yes ;-) If all stops were clean, we wouldn't need
fail-over software ;-)

(I'd suggest to compute the string in some function somewhere, to make
sure its always identical. Typos creep in way too quickly.)

The monitor op probably should also check whether this file exists
before trying to IO to it.

> > I'd suggest conv=fdatasync/fsync instead of flag=direct.
> The other Lars suggested that as well. :) But what about reads? Is there
> any filesystem-agnostic way of saying "I want to read what's on disk,
> rather than in cache" that's actually _better_ than opening the file
> with O_DIRECT (realizing that it's a no-op for some filesystems)?

For reading you're right, yes.

Regards,
Lars

--
Architect Storage/HA, OPS Engineering, Novell, Inc.
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 [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

lmb at suse

Sep 18, 2009, 4:17 AM

Post #12 of 17 (3138 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

On 2009-09-16T19:44:32, Dejan Muhamedagic <dejanmm [at] fastmail> wrote:

> > Quite simple, really. ;-)
> Makes sense. I'd just like to avoid that the parameter is
> required to run monitor operation.

Right, a depth=0, nothing should change from today.

Regards,
Lars

--
Architect Storage/HA, OPS Engineering, Novell, Inc.
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 [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

dejanmm at fastmail

Oct 12, 2009, 4:16 AM

Post #13 of 17 (2688 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

Hi Florian,

This discussion digressed, and I'm not entirely happy with the
current user interface/implementation. Do you intend to do
something about it?

Cheers,

Dejan

On Wed, Sep 16, 2009 at 02:41:35PM +0200, Dejan Muhamedagic wrote:
> 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: Linux-HA-Dev [at] lists
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> > Home Page: http://linux-ha.org/
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

florian.haas at linbit

Oct 12, 2009, 4:27 AM

Post #14 of 17 (2697 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

On 2009-10-12 13:16, Dejan Muhamedagic wrote:
> Hi Florian,
>
> This discussion digressed, and I'm not entirely happy with the
> current user interface/implementation. Do you intend to do
> something about it?

Certainly: I just happen to be swamped at this point. :)

I must confess I am not entirely happy with the suggestions on the
table. AIUI, the currently prevalent notion is to check for the status
file only if $OCF_CHECK_LEVEL is set to nonzero. But that means I can't
create the status file on start, nor clean it up on stop -- as, when
$OCF_CHECK_LEVEL is defined on the monitor ops as the documentation
sensibly suggests, the check level is passed in only during the monitor
operation. I'd be grateful for suggestions here.

Cheers,
Florian

Attachments:

signature.asc (0.25 KB)

dejanmm at fastmail

Oct 12, 2009, 4:48 AM

Post #15 of 17 (2712 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

Hi,

On Mon, Oct 12, 2009 at 01:27:55PM +0200, Florian Haas wrote:
> On 2009-10-12 13:16, Dejan Muhamedagic wrote:
> > Hi Florian,
> >
> > This discussion digressed, and I'm not entirely happy with the
> > current user interface/implementation. Do you intend to do
> > something about it?
>
> Certainly: I just happen to be swamped at this point. :)

If you're swamped beyond recovery, I can do the changes :)
The problem is that there may be a release and we don't want to
release an interface which is going to change.

> I must confess I am not entirely happy with the suggestions on the
> table.

Let's talk :)

> AIUI, the currently prevalent notion is to check for the status
> file only if $OCF_CHECK_LEVEL is set to nonzero.

Right.

> But that means I can't
> create the status file on start, nor clean it up on stop -- as, when
> $OCF_CHECK_LEVEL is defined on the monitor ops as the documentation
> sensibly suggests, the check level is passed in only during the monitor
> operation. I'd be grateful for suggestions here.

For the read-only test, just do "ls -d $directory/." For the
read-write test you'll have to rewrite a file anyway. As
discussed, it'd be good to have some kind of default in this
case, probably in an extra directory such as
"./.Filesystem_monitor/".

Cheers,

Dejan

> Cheers,
> Florian
>

> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

florian.haas at linbit

Oct 12, 2009, 9:33 AM

Post #16 of 17 (2696 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

On 10/12/2009 01:48 PM, Dejan Muhamedagic wrote:
> Hi,
>
> On Mon, Oct 12, 2009 at 01:27:55PM +0200, Florian Haas wrote:
>> On 2009-10-12 13:16, Dejan Muhamedagic wrote:
>>> Hi Florian,
>>>
>>> This discussion digressed, and I'm not entirely happy with the
>>> current user interface/implementation. Do you intend to do
>>> something about it?
>> Certainly: I just happen to be swamped at this point. :)
>
> If you're swamped beyond recovery, I can do the changes :)

I'm not swamped beyond recovery, but I really wouldn't mind if you
implemented the changes because it seems I fail to fully grasp exactly
what functionality changes you have in mind. :) Would it be OK if you
committed the changes you see fit, and I'd help out testing?

Cheers,
Florian

Attachments:

signature.asc (0.25 KB)

dejanmm at fastmail

Oct 12, 2009, 10:28 AM

Post #17 of 17 (2694 views)
Permalink

Re: Monitor operation for the Filesystem RA [In reply to]

Hi,

On Mon, Oct 12, 2009 at 06:33:50PM +0200, Florian Haas wrote:
> On 10/12/2009 01:48 PM, Dejan Muhamedagic wrote:
> > Hi,
> >
> > On Mon, Oct 12, 2009 at 01:27:55PM +0200, Florian Haas wrote:
> >> On 2009-10-12 13:16, Dejan Muhamedagic wrote:
> >>> Hi Florian,
> >>>
> >>> This discussion digressed, and I'm not entirely happy with the
> >>> current user interface/implementation. Do you intend to do
> >>> something about it?
> >> Certainly: I just happen to be swamped at this point. :)
> >
> > If you're swamped beyond recovery, I can do the changes :)
>
> I'm not swamped beyond recovery, but I really wouldn't mind if you
> implemented the changes because it seems I fail to fully grasp exactly
> what functionality changes you have in mind. :) Would it be OK if you
> committed the changes you see fit, and I'd help out testing?

Sure.

Cheers,

Dejan

> Cheers,
> Florian
>

> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads