Re: [SSI-devel] [DRBD] drbd-0.7.7-ssi_pre19.patch
Brought to you by:
brucewalker,
rogertsang
From: Roger T. <op...@bl...> - 2005-02-17 00:46:15
|
>>> How does drbd handle the syncing of these two nodes when they coming >>> back and are able to talk to >>> each other? Which one is determined to be the primary copy? >>> >> >> in case of Debian who ever is the CFS server for root is the primary >> for all DRBD resources. >> >> >> -aneesh >> > Shouldnt it be left to the sysadmin to decide which one should be the > primary in case of a conflict? The other copy might be the more recent > one. > Jaideep, It seems DRBD can determine which one is *actually* newer according to the its meta-data. I have a question. In your drbd-pre0.7 attempt you commented out a few sections in drbd_receiver.c: drbd_asender() starting with if (test_and_clear_bit(SEND_PING, &mdev->flags)) { ERR_IF(!drbd_send_ping(mdev)) goto err; // half ack timeout only, // since sendmsg waited the other half already mdev->meta.socket->sk->SK_(rcvtimeo) = mdev->conf.timeout*HZ/20; } Do you recall what problem we had with this in SSI? I'm testing a new scenario in SSI where Primary DRBD is connected to a *non-SSI* Secondary DRBD. The SSI machine running DRBD Primary would freeze when the Secondary DRBD becomes unreachable, but the machine resumes when Secondary DRBD is restored. I believe that is the only remaining code in SSI-DRBD that I haven't touched yet. Of course this does not happen when both DRBD nodes are in the same SSI cluster. Someone might setup DRBD connections between separate/remote SSI clusters and this is my primary concern. Thanks, Roger |