Hi Dejan,
Dejan Muhamedagic wrote:
On Thu, Aug 23, 2007 at 05:25:44PM +0100, Ben Clewett wrote:
Hi,
Probably me misunderstanding you :)
(This is probably more for the linux-ha mailing list now, but it may be
of interest here...)
There are various parameters in the Filesystem ocf:
<actions>
<action name="start" timeout="60" />
<action name="stop" timeout="60" />
<action name="notify" timeout="60" />
<action name="monitor" depth="0" timeout="40" interval="20"
start-delay="10" />
<action name="validate-all" timeout="5" />
<action name="meta-data" timeout="5" />
</actions>
But this is odd. The start timeout shows as 60s. Yet linux-ha killed
the mount operation after 10 seconds, therefore making drbd permanently
stale. Is this another bug?
Probably not. Or, let's say that it's probably a documentation
bug. Actually, I'm also not sure why, but what is apparently
used as the timeout is the default-action-timeout from the
cluster_property_set.
Thanks for the details. I'm not sure where to find the
cluster_property_set, but I will change this and see if it helps things.
This was really my reason for mailing, I wanted to see if there were any
ocf experts out there... As well as to report a possible bug.
Well, on the one hand what you encountered was definitely a
surprise, perhaps the default timeout should be raised. On the
other hand, you should normally try to run all resources, or at
least those about which you are not sure how they are going to
behave and I'd expect a 3TB filesystem to be in that category, by
hand before starting them by the cluster.
That would be an excelent idea. However I need this to be avaiable.
Therefore if we loose the server/switch/power/building, linux-ha will
mount this on the other server. Which is 100m down a 1000baseF link.
I will battle on with my problem :)
Thanks for the feedback,
Ben
I am making better progress by upping all these values. If I find
anything of significant interest, I'll report back :)
Ben
matilda matilda wrote:
Ben Clewett <[EMAIL PROTECTED]> 23.08.2007 17:38 >>>
The reason for this email is just to note to the group that a large file
system under drbd mounted by the latest linux-ha will cause a problem
which can only be sorted by a complete re-boot.
I hope this will be useful, and somebody may decide it's a bug worth
investigation...
Hi Ben,
I'm sure you misunderstood me, but probably I misunderstand you. :-)
As I said in my first answer: You HAVE to increase the timeout value
for the start operation of your Resource Agent. As you said in your
initial mail, your RA times out before the big filesystem CAN be
mounted because of its size. You CAN set a timeout for every
action of every resource overwriting the default action timeout.
So, really, enhance the timeout value to a real comfortable value.
It's better to make it too big than too small.
If you already made this forget this mail. :-)
Best regards
Andreas
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
*************************************************************************
This e-mail is confidential and may be legally privileged. It is intended
solely for the use of the individual(s) to whom it is addressed. Any
content in this message is not necessarily a view or statement from Road
Tech Computer Systems Limited but is that of the individual sender. If
you are not the intended recipient, be advised that you have received
this e-mail in error and that any use, dissemination, forwarding,
printing, or copying of this e-mail is strictly prohibited. We use
reasonable endeavours to virus scan all e-mails leaving the company but
no warranty is given that this e-mail and any attachments are virus free.
You should undertake your own virus checking. The right to monitor e-mail
communications through our networks is reserved by us
Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley,
Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17
Registered in England No: 02017435, Registered Address: Charter Court,
Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE.
*************************************************************************
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
*************************************************************************
This e-mail is confidential and may be legally privileged. It is intended
solely for the use of the individual(s) to whom it is addressed. Any
content in this message is not necessarily a view or statement from Road
Tech Computer Systems Limited but is that of the individual sender. If
you are not the intended recipient, be advised that you have received
this e-mail in error and that any use, dissemination, forwarding,
printing, or copying of this e-mail is strictly prohibited. We use
reasonable endeavours to virus scan all e-mails leaving the company but
no warranty is given that this e-mail and any attachments are virus free.
You should undertake your own virus checking. The right to monitor e-mail
communications through our networks is reserved by us
Road Tech Computer Systems Ltd. Shenley Hall, Rectory Lane, Shenley,
Radlett, Hertfordshire, WD7 9AN. - VAT Registration No GB 449 3582 17
Registered in England No: 02017435, Registered Address: Charter Court,
Midland Road, Hemel Hempstead, Hertfordshire, HP2 5GE.
*************************************************************************
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
