Grant Henke has uploaded this change for review. (
Change subject: KUDU-2153. Servers should not delete tmp files until after
KUDU-2153. Servers should not delete tmp files until after locking directories
This changes the order of FsManager startup to not try to clean tmp
files until after successfully locking the data directories. This
prevents potential issues such as:
- a tserver is already running on some host, and in the middle of
consensus voting. Thus it has created a tmp file.
- someone accidentally attempts to start a tserver with the same set of
data dirs. Prior to this patch, it would delete the tmp file before
realizing that it could not successfully lock its data dirs and
- the original tserver would crash or otherwise get very confused
because the tmp file it just wrote would be gone.
This patch relies on the locking on the block manager instance files to
provide exclusive access to some non-block-manager-related storage such
as the consensus meta, etc. That means that it's still possible for
someone to hit the above issue if they were to start servers with
disjoint sets of data dirs but with the same meta dir. However, the
patch is still a net improvement because the most likely scenario is
that the two servers are started with identical configurations.
This patch also removes the block_manager_lock_dirs flag which was
apparently unused. It was always marked as 'unsafe' so it's not a
compatibility issue to remove it without a deprecation period.
Reviewed-by: Adar Dembo <a...@cloudera.com>
Tested-by: Todd Lipcon <t...@apache.org>
(cherry picked from commit d88e5772ee323c8a305250c7d0aa0b49f67475dc)
6 files changed, 49 insertions(+), 24 deletions(-)
git pull ssh://gerrit.cloudera.org:29418/kudu refs/changes/22/9622/1
To view, visit http://gerrit.cloudera.org:8080/9622
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Owner: Grant Henke <granthe...@gmail.com>
Gerrit-Reviewer: Todd Lipcon <t...@apache.org>