Resolve code review comments:
1) Improve the code efficiency by avoiding unnecessary map search
and avoiding unnecessary checking
2) Remove or comment out trace events when they can be spammy
3) Improve coding style
Tested for 1 hour and no error was found.
KillRegionCycle.txt test was excluded from the test because
existing code cannot pass that test either
Signed-off-by: Meng Xu <meng_xu@apple.com>
Current server team collection logic does not consider
the fact that multipe storage servers can run on the same machine.
When multiple machines fail, all servers on the machines will fail, and
the possibility of having one process team fail and lose data is very high.
To reduce the possibility of losing data when multiple machine fails,
we first create machine teams which span across different fault zones;
we then create server teams based on machine teams by
first picking 1 machine team, and then
picking 1 server from each machine in the machine team.
Signed-off-by: Meng Xu <meng_xu@apple.com>
The bindings build was broken becaue fdb_c_performance_test failed to
link with errors of the form:
/tmp/ccym9LhK.o: In function `clearAll':
/opt/foundationdb/bindings/c/test/performance_test.c:130: undefined reference to `fdb_transaction_clear_range'
/tmp/ccym9LhK.o: In function `insertRange':
/opt/foundationdb/bindings/c/test/performance_test.c:139: undefined reference to `fdb_transaction_set'
/tmp/ccym9LhK.o: In function `singleKey':
/opt/foundationdb/bindings/c/test/performance_test.c:540: undefined reference to `fdb_transaction_set'
...
PR #901's e8f20e4 fixed this by adding `-shared` to the invocation line,
and thus doing a dynamic linking of libfdb_c.
As dynamically linking produced a working executable, this suggests that
the correct set of libraries are being linked, as the symbols can be
located eventually, just not in the right order, as the linker will
proactively not include unnecessary object files from static libraries.
And unfortunately, our performance test framework likely expects to be able
to copy the binary, and not have to worry about associated dynamically
linked libraries, so a statically linked binary is preferred.
The underlying cause of this link error is that the static library
preceeded the source code in the command line:
/usr/bin/gcc -Werror -Wno-error=format -fPIC -DNO_INTELLISENSE -fvisibility=hidden -DNDEBUG=1 -Wreturn-type -fno-omit-frame-pointer -O2 -g -Llib -lfdb_c -lpthread -Ibindings/c -o bin/fdb_c_performance_test bindings/c/test/performance_test.c
This comes from the line in the Makefile:
@$(CC) $(CFLAGS) $(fdb_c_tests_LIBS) $(fdb_c_tests_HEADERS) -o $@ bindings/c/test/performance_test.c
As we pass `-lfdb_c` before `performance_test.c`, when the linker is
considering libfdb_c.a, it sees that no symbols from any of the object
files are currently needed, and thus doesn't include them. When we
proceprocess performance_test.c, we suddenly need these symbols, but
it's too late, as the linker only processes files left-to-right.
Thus, we can resolve this problem by passing -lfdb_c after performance_test.c
Also of note is that we only seem to have this problem because the link
line was crafted by hand instead of using link-wrapper.sh, which already
does the right thing.
Evan Tschannen