Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2006-05-30 12:40:12 -0500 \ Dave Dykstra: > Reviving an old thread ... thanks for the reminder... > > > > I think that doing multiple tries in the drbddisk command is a > > > > hack, though, especially since it doesn't take into account any > > > > change in the "timeout" parameter that there may be in > > > > drbd.conf. I think the 'drbdsetup primary' command (possibly > > > > with a new option that drbddisk invokes) should try to contact > > > > the remote side and wait until there is either a positive > > > > response or a timeout before it exits with an error. > > > > > > what is there is a "hack". > > > > > > it is a misconfiguration, when heartbeat deadtime was > > > smaller than drbd ping time, though. > > > > > > still it could be desirable to have an option like that outlined > > > above, "drbdsetup /dev/drbd0 primary --I-think-peer-is-dead", and > > > this option would typically be used by the heartbeat resource > > > script/agent. > > > > I think rather it should be something like > > --I-think-peer-may-be-dead because the heartbeat resource script > > would do the same thing no matter how it is coming up. > > > > > this will probably be implemented in 0.8 ... > > I see that the latest 8.0 pre-release code in subversion is still > using a loop count of 6 in the drbddisk script and is not using an > option like one we discussed. If this is still quite low on the > priority list, I suggest that the loop count maximum in drbddisk be > increased for now because it's easy and it does work. > > Lars, what do you think? we put this on the roadmap again. but actually, since we (try to) do certain state changes now with "cluster wide synchronisation", this should be a non issue meanwhile for drbd8 svn, and the retry loop in the script can probably go. maybe we don't do this correctly yet and bail out too early without verification whether what we think about the peers status is still true. but that would be a bug and should be fixed. -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schoenbrunner Str. 244, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client.