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: [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/
