Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, >> > DRBD has _two_ tcp sessions per device, >> > one end will have a "random high port", >> > the end the configured port. >> >> Are these two sessions for "data" and "meta" socket as you mentioned below? >> I think I want to simulate the blocking of "meta" socket. > > Ah. Why? > Please step back bit and suggest which _real world_ scenario > you have in mind. What is it that you are trying to prove or analyse? > > Appart from sniffing the traffic, there is no easy way to > determine which is which just from looking at it. I want to reproduce the following situation. Primary can send "data" to Secondary, but only "meta data" is dropped unfortunately. It might be a unrealistic worry... >> DRBD can not replicate the data if "data" socket is blocked >> and DRBD reopen the new socket if "meta" socket is blocked, >> Is that right? > > No. > If one of the sockets is detected to not work, > both are dropped, and eventually reestablished. ok, that means, in my previous test that I could _by chance_ blocked the "data" socket, the socket should be eventually reestablished. Is there any special delay for only "data" socket? Does "delay_prove" have some relation? http://kerneltrap.org/mailarchive/git-commits-head/2010/5/22/38405 I have to try again anyway. >> the result is; >> >> * protocol B,C >> DRBD did nothing. > > You _by chance_ only blocked the "data" socket. > >> * protocol A >> It seems that DRBD restarted its threads. > > You _by chance_ happened to block the "meta" socket.>> the result is; >> >> * protocol B,C >> DRBD did nothing. > > You _by chance_ only blocked the "data" socket. > >> * protocol A >> It seems that DRBD restarted its threads. > > You _by chance_ happened to block the "meta" socket. by the way, sorry for the direct reply to your address... Thanks, Junko