Andrew Wong has posted comments on this change. ( http://gerrit.cloudera.org:8080/9027 )
Change subject: KUDU-1489: allow configuration of metadata dir ...................................................................... Patch Set 7: (9 comments) Done, and added a more integration-y test per David's feedback. http://gerrit.cloudera.org:8080/#/c/9027/6/src/kudu/fs/block_manager_util.cc File src/kudu/fs/block_manager_util.cc: http://gerrit.cloudera.org:8080/#/c/9027/6/src/kudu/fs/block_manager_util.cc@176 PS6, Line 176: > typo Done http://gerrit.cloudera.org:8080/#/c/9027/6/src/kudu/fs/fs_manager-test.cc File src/kudu/fs/fs_manager-test.cc: http://gerrit.cloudera.org:8080/#/c/9027/6/src/kudu/fs/fs_manager-test.cc@248 PS6, Line 248: "wal" > could we be more specific? maybe look for full suffix? Done http://gerrit.cloudera.org:8080/#/c/9027/6/src/kudu/fs/fs_manager-test.cc@255 PS6, Line 255: LOG(INFO) << s.ToString(); > leftover from testing? if you want to print the status on failure you can d Done http://gerrit.cloudera.org:8080/#/c/9027/6/src/kudu/fs/fs_manager-test.cc@258 PS6, Line 258: : TEST_F(FsManagerTestBase, TestMetadataDirInData > check the status Per Adar's comment, I moved these each into their own test. http://gerrit.cloudera.org:8080/#/c/9027/6/src/kudu/fs/fs_manager-test.cc@263 PS6, Line 263: : // Creating a brand new FS layout configured with metadata in the first data : // directory emulates the default behavior in Kudu 1.6 and below. : opts.metadata_root = GetTestPath("data"); : ReinitFsManagerWithOpts(opts); > in the case before this one you test with a metadata root path that does no Done http://gerrit.cloudera.org:8080/#/c/9027/6/src/kudu/fs/fs_manager-test.cc@269 PS6, Line 269: ASSERT_OK(fs_manager()->Open()); : ASSERT_STR_CONTAINS(fs_manager()->GetTabletMetadataDir(), "data"); > wait, empty string is different from "unset"? why? Mm, not sure I understand, what do you mean by "unset" here? This behavior is for backwards compatibility: older deployments can continue running with no change to their configurations (i.e. with an empty fs_metadata_dir flag) while maintaining that their metadata will be in the first data dir. New deployments will use the fs_wal_dir for metadata if fs_metadata_dir is empty. http://gerrit.cloudera.org:8080/#/c/9027/6/src/kudu/fs/fs_manager-test.cc@276 PS6, Line 276: ASSERT_OK(fs_manager()->Open()); : ASSERT_STR_CONTAINS(fs_manager()->GetTabletMe > same Ack http://gerrit.cloudera.org:8080/#/c/9027/7/src/kudu/fs/fs_manager-test.cc File src/kudu/fs/fs_manager-test.cc: http://gerrit.cloudera.org:8080/#/c/9027/7/src/kudu/fs/fs_manager-test.cc@534 PS7, Line 534: // Adding a new data dir elsewhere in the list is OK. > This isn't what the test does anymore though; it's just shuffling the order Ah you're right, my bad. Removing it. I'll add a similar test up where we test metadata in the first data root. http://gerrit.cloudera.org:8080/#/c/9027/4/src/kudu/fs/fs_manager.cc File src/kudu/fs/fs_manager.cc: http://gerrit.cloudera.org:8080/#/c/9027/4/src/kudu/fs/fs_manager.cc@256 PS4, Line 256: const string meta_dir_in_data_root = JoinPathSegments(canonicalized_data_fs_roots_[0].path, > My concern is with the following sequence: I see. Step 3 would fail at CreateFileSystemRoots(). The canonicalized roots wouldn't be empty, so this would lead to an AlreadyPresent error. -- To view, visit http://gerrit.cloudera.org:8080/9027 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I375c6b2eb283db5fa9c956135d98252c8781f5db Gerrit-Change-Number: 9027 Gerrit-PatchSet: 7 Gerrit-Owner: Andrew Wong <[email protected]> Gerrit-Reviewer: Adar Dembo <[email protected]> Gerrit-Reviewer: Andrew Wong <[email protected]> Gerrit-Reviewer: David Ribeiro Alves <[email protected]> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Tidy Bot Gerrit-Comment-Date: Wed, 17 Jan 2018 02:57:03 +0000 Gerrit-HasComments: Yes
