Hello David Ribeiro Alves, Todd Lipcon,

I'd like you to do a code review.  Please visit

    http://gerrit.cloudera.org:8080/6682

to review the following change.

Change subject: block manager: gflag to control repairs at startup
......................................................................

block manager: gflag to control repairs at startup

This patch introduces a gflag that controls which block manager repairs are
undertaken at startup. Its three states are:
- all: all inconsistencies are repaired.
- some (default): only "cheap" inconsistencies are repaired.
- none: no repairs are performed.

The idea is that regular server startup will only detect and repair some
stuff, while "kudu fs check" will detect (and optionally repair) everything.

As far as the LBM is concerned, 'all' means inconsistency checks that need
extent maps (expensive!) will be performed. Moreover, 'none' introduces some
complexity for fatal and repairable inconsistencies (i.e. partial records).

Note: the new gflag is a little overloaded; sometimes it deals with both
detection and repair (i.e. full container preallocation inconsistencies when
'all') while other times it's just repair (i.e. partial record
inconsistencies when 'none'). Feedback welcome on how to address that.

Change-Id: I06750991e1ede07ab7173a3cc5de12279d3f5b88
---
M src/kudu/fs/block_manager.cc
M src/kudu/fs/fs_report.cc
M src/kudu/fs/fs_report.h
M src/kudu/fs/log_block_manager-test.cc
M src/kudu/fs/log_block_manager.cc
M src/kudu/tools/tool_action_fs.cc
6 files changed, 102 insertions(+), 24 deletions(-)


  git pull ssh://gerrit.cloudera.org:29418/kudu refs/changes/82/6682/1
-- 
To view, visit http://gerrit.cloudera.org:8080/6682
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I06750991e1ede07ab7173a3cc5de12279d3f5b88
Gerrit-PatchSet: 1
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Adar Dembo <a...@cloudera.com>
Gerrit-Reviewer: David Ribeiro Alves <dral...@apache.org>
Gerrit-Reviewer: Todd Lipcon <t...@apache.org>

Reply via email to