Date: Wed, 27 Apr 2011 19:46:57 +0000 (UTC) From: Mikolaj Golub <trociny@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sbin/hastctl hastctl.8 hastctl.c src/sbin/hastd activemap.c hast_proto.c hast_proto.h hastd.c parse.y primary.c secondary.c Message-ID: <201104271947.p3RJl8CR098842@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
trociny 2011-04-27 19:46:57 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_8)
sbin/hastctl hastctl.8 hastctl.c
sbin/hastd activemap.c hast_proto.c hast_proto.h
hastd.c parse.y primary.c secondary.c
Log:
SVN rev 221135 on 2011-04-27 19:46:57Z by trociny
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)
Revision Changes Path
1.1.2.5 +2 -2 src/sbin/hastctl/hastctl.8
1.1.2.6 +1 -1 src/sbin/hastctl/hastctl.c
1.1.2.4 +1 -1 src/sbin/hastd/activemap.c
1.1.2.7 +5 -25 src/sbin/hastd/hast_proto.c
1.1.2.4 +0 -2 src/sbin/hastd/hast_proto.h
1.2.2.13 +8 -1 src/sbin/hastd/hastd.c
1.1.2.8 +12 -1 src/sbin/hastd/parse.y
1.3.2.14 +68 -13 src/sbin/hastd/primary.c
1.1.2.10 +1 -0 src/sbin/hastd/secondary.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201104271947.p3RJl8CR098842>