K 10
svn:author
V 7
trociny
K 8
svn:date
V 27
2011-04-27T19:46:57.234103Z
K 7
svn:log
V 1905
MFC r220520, r220521, r220522, r220523, r220573, r220744, r220865,
  r220889, r220890, r220898, r220899:

r220520:

hastd(8) maintains a map of dirty extents, not hastctl(8). Fix this.

r220521:

Fix a typo in comments.

r220522:

In hast_proto_recv_data() check that the size of the data to be
received does not exceed the buffer size.

r220573 (pjd):

The replication mode that is currently support is fullsync, not memsync.
Correct this and print a warning if different replication mode is
configured.

r220523, r220744:

Remove hast_proto_recv(). It was used only in one place, where
hast_proto_recv_hdr() may be used.

r220865 (pjd):

Scenario:
- We have two nodes connected and synchronized (local counters on both sides
  are 0).
- We take secondary down and recreate it.
- Primary connects to it and starts synchronization (but local counters are
  still 0).
- We switch the roles.
- Synchronization restarts but data is synchronized now from new primary
  (because local counters are 0) that doesn't have new data yet.

This fix this issue we bump local counter on primary when we discover that
connected secondary was recreated and has no data yet.

Reported by:    trociny
Discussed with: trociny
Tested by:      trociny

r220889 (pjd):

Timeout must be positive.

r220890 (pjd):

If we act in different role than requested by the remote node, log it
as a warning and not an error.

MFC after:      1 week

r220898 (pjd), r220899 (pjd):

When we become primary, we connect to the remote and expect it to be in
secondary role. It is possible that the remote node is primary, but only
because there was a role change and it didn't finish cleaning up (unmounting
file systems, etc.). If we detect such situation, wait for the remote node
to switch the role to secondary before accepting I/Os. If we don't wait for
it in that case, we will most likely cause split-brain.

Approved by:	pjd (mentor)

END