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: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
