From: Lars Ellenberg <lars.ellenberg@linbit.com>
To: drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] too small timeout in drbdsetup
Date: Wed, 6 Aug 2008 10:53:08 +0200 [thread overview]
Message-ID: <20080806085308.GB32114@soda.linbit> (raw)
In-Reply-To: <873aljpey0.871w13pey0@87zlnro0dk.message.id>
On Tue, Aug 05, 2008 at 07:15:20PM +0200, syrius.ml@no-log.org wrote:
> Philipp Reisner <philipp.reisner@linbit.com> writes:
>
> > We do not experience any issue with the 500ms in our setups, as are reports
> > about such an issue rather rare. Could you give a more details description
> > about the conditions you trigger can trigger this ?
>
> I have several drbd devices (4 atm).
> Most of the time it is triggered by heartbeat RA scripts when the
> device are setup one after the other.
> could also happen if i do "echo r1 r2 r3 r4 | xargs -n 1 drbdadm
> primary" for example.
>
> > I guess we will add an option to drbdsetup then, and have it is setting
> > in the globals section of drbd.conf.
>
> sounds good.
>
> > I do not want to inrecase it for all users, since is seems to affect only
> > a very small part of our user base.
it may well affect all.
sometimes we do something that involves IO from the context of the
cqueue thread. we probably should not.
if I have too few of them (typically depends on number of cores), and
all are busy (for a second or so), any communication attempt with a
500ms timeout will time out while they are still processing the previous
command.
I'd suggest to replace that check function by a simple stat on
/proc/drbd. The netlink path will be exercised by the next command
anyways, with a much larger timeout. The extra call with short timeout
in the beginning was just a convenience to not run into the full timeout
and only then realize that the module is missing.
The only drawback I can see to this aproach is, that if now someone loads
a pre-DRBD-8 module (0.7, 0.6), but uses DRBD-8 userland, the driver
would appear to be loaded, and drbdsetup will then still run into the
full timeout of the respective commands.
yes, stupid things do happen.
but, how much do we care?
--
: Lars Ellenberg Tel +43-1-8178292-55 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Vivenotgasse 48, A-1120 Vienna/Europe http://www.linbit.com :
next prev parent reply other threads:[~2008-08-06 8:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-14 17:24 [Drbd-dev] too small timeout in drbdsetup syrius.ml
2008-08-04 18:37 ` syrius.ml
2008-08-05 11:35 ` Philipp Reisner
2008-08-05 17:15 ` syrius.ml
2008-08-06 8:53 ` Lars Ellenberg [this message]
2008-08-12 9:58 ` Nikola Ciprich
2008-08-05 12:54 ` Graham, Simon
-- strict thread matches above, loose matches on Subject: below --
2008-08-14 7:57 Jerome Martin
2008-08-16 15:27 ` Lars Ellenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080806085308.GB32114@soda.linbit \
--to=lars.ellenberg@linbit.com \
--cc=drbd-dev@lists.linbit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox