Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mon, Feb 02, 2009 at 05:20:23PM +0100, Rainer Sabelka wrote: > > > To work around the problem I've now put DRBD into stand alone mode. > > > Is there anything else I can do about this? > > > > fix the network link? > > Yes of course this is being worked on. But since the problem occurs only > transiently its not easy to identify the faulty component. > > > well, seriously: what would you like DRBD to do? > > Allow IO to the local disk during transfer of the bitmap. > > However, I'm not sure if this would be possible since this would mean that the > bitmap changes during the transfer. Maybe this could be handled with a second > bitmap to keep track which blocks of the first bitmap have been altered during > the transfer and need to be re-transmitted. But I feel this is starting to get > complicated ... and it would not even help in your situation. if the connection is too slow (due to noise or packet loss) to transfer the bitmap, any IO would certainly feel "stalled" as well. > > > Jan 30 11:21:33 server2 kernel: drbd0: [drbd0_worker/13962] sock_sendmsg > > > time expired, ko = 19 > > > > if you configure your ko count smaller, > > then if it actually reaches zero, > > drbd stays disconnected (StandAlone), > > until you tell it to reconnect explicitly. > > I just tried this on a pair of test machines (with ko-count=5). > But DRBD always tries to reconnect. hm. it should not. if ko-count reaches zero, DRBD is supposed to go StandAlone. you say it just does a disconnect/reconnect cycle. guess we have to have a look at this more closely. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed