Improve consistency checks in VersionBuilder #6901

ltamasi · 2020-06-01T18:39:14Z

Summary:
The patch cleans up the code and improves the consistency checks around
adding/deleting table files in VersionBuilder. Namely, it makes the checks
stricter and improves them in the following ways:

A table file can now only be deleted from the LSM tree using the level it
resides on. Earlier, there was some unnecessary wiggle room for
trivially moved files (they could be deleted using a lower level number than
the actual one).
A table file cannot be added to the tree if it is already present in the tree
on any level (not just the target level). The earlier code only had an assertion
(which is a no-op in release builds) that the newly added file is not already
present on the target level.
The above consistency checks around state transitions are now mandatory,
as opposed to the earlier CheckConsistencyForDeletes, which was a no-op
in release mode unless force_consistency_checks was set to true. The rationale
here is that assuming that the initial state is consistent, a valid transition leads to a
next state that is also consistent; however, an invalid transition offers no such
guarantee. Hence it makes sense to validate the transitions unconditionally,
and save force_consistency_checks for the paranoid checks that re-validate
the entire state.
The new checks build on the mechanism introduced in Make it possible to look up files by number in VersionStorageInfo #6862,
which enables us to efficiently look up the location (level and position within level)
of files in a Version by file number. This makes the consistency checks much more
efficient than the earlier CheckConsistencyForDeletes, which essentially
performed a linear search.

Test Plan:
Extended the unit tests and ran:

make check
make whitebox_crash_test

…methods

…t; extend the consistency checks and make them non-optional

…ls_ is no longer needed, just the sizes

…eletion, small cleanup

… removed, or removed then readded

facebook-github-bot

@ltamasi has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

facebook-github-bot

@ltamasi has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

ajkr · 2020-06-03T17:18:03Z

db/version_builder.cc

  // storing them in levels_ to avoid regression in case there are no files
  // on invalid levels. The version is not consistent if in the end the files
  // on invalid levels don't cancel out.
-  std::map<int, std::unordered_set<uint64_t>> invalid_levels_;
+  std::unordered_map<int, size_t> invalid_level_sizes_;


I know this is existing code, but do you happen to know under what condition we add or delete files from an invalid level?
edit: nvm the original commit explained it well enough (replay manifest while reopening DB with decreased num_levels).

ajkr

looks great! the new logic makes sense to me.

ajkr · 2020-06-03T17:43:09Z

db/version_builder.cc

+    auto& del_files = level_state.deleted_files;
+    auto del_it = del_files.find(file_number);
+    if (del_it != del_files.end()) {
+      del_files.erase(del_it);


Do we have to allow this case (a file is added after being deleted causing them to cancel out)?

Good question. This path is currently not triggered by any actual VersionEdit but I would still keep it for the sake of completeness.

facebook-github-bot · 2020-06-03T18:38:42Z

@ltamasi merged this pull request in 78e291b.

…level (#6939) Summary: #6901 subtly changed the handling of the corner case when a table file is deleted from a level, then re-added to the same level. (Note: this should be extremely rare; one scenario that comes to mind is a trivial move followed by a call to `ReFitLevel` that moves the file back to the original level.) Before that change, a new `FileMetaData` object was created as a result of this sequence; after the change, the original `FileMetaData` was essentially resurrected (since the deletion and the addition simply cancel each other out with the change). This patch restores the original behavior, which is more intuitive considering the interface, and in sync with how trivial moves are handled. (Also note that `FileMetaData` contains some mutable data members, the values of which might be different in the resurrected object and the freshly created one.) The PR also fixes a bug in this area: with the original pre-6901 code, `VersionBuilder` would add the same file twice to the same level in the scenario described above. Pull Request resolved: #6939 Test Plan: `make check` Reviewed By: ajkr Differential Revision: D21905580 Pulled By: ltamasi fbshipit-source-id: da07ae45384ecf3c6c53506d106432d88a7ec9df

Summary: `VersionSet::VerifyCompactionFileConsistency` was superseded by the LSM tree consistency checks introduced in facebook#6901, which are more comprehensive, more efficient, and are performed unconditionally even in release builds. Test Plan: `make check`

…8449) Summary: `VersionSet::VerifyCompactionFileConsistency` was superseded by the LSM tree consistency checks introduced in #6901, which are more comprehensive, more efficient, and are performed unconditionally even in release builds. Pull Request resolved: #8449 Test Plan: `make check` Reviewed By: ajkr Differential Revision: D29337441 Pulled By: ltamasi fbshipit-source-id: a05324f88e3400e27e6a00406c878a6276e0c9cc

Summary: The patch cleans up the code and improves the consistency checks around adding/deleting table files in `VersionBuilder`. Namely, it makes the checks stricter and improves them in the following ways: 1) A table file can now only be deleted from the LSM tree using the level it resides on. Earlier, there was some unnecessary wiggle room for trivially moved files (they could be deleted using a lower level number than the actual one). 2) A table file cannot be added to the tree if it is already present in the tree on any level (not just the target level). The earlier code only had an assertion (which is a no-op in release builds) that the newly added file is not already present on the target level. 3) The above consistency checks around state transitions are now mandatory, as opposed to the earlier `CheckConsistencyForDeletes`, which was a no-op in release mode unless `force_consistency_checks` was set to `true`. The rationale here is that assuming that the initial state is consistent, a valid transition leads to a next state that is also consistent; however, an *invalid* transition offers no such guarantee. Hence it makes sense to validate the transitions unconditionally, and save `force_consistency_checks` for the paranoid checks that re-validate the entire state. 4) The new checks build on the mechanism introduced in facebook#6862, which enables us to efficiently look up the location (level and position within level) of files in a `Version` by file number. This makes the consistency checks much more efficient than the earlier `CheckConsistencyForDeletes`, which essentially performed a linear search. Pull Request resolved: facebook#6901 Test Plan: Extended the unit tests and ran: `make check` `make whitebox_crash_test` Reviewed By: ajkr Differential Revision: D21822714 Pulled By: ltamasi fbshipit-source-id: e2b29c8b6da1bf0f59004acc889e4870b2d18215 Signed-off-by: tabokie <xy.tao@outlook.com>

…level (facebook#6939) Summary: facebook#6901 subtly changed the handling of the corner case when a table file is deleted from a level, then re-added to the same level. (Note: this should be extremely rare; one scenario that comes to mind is a trivial move followed by a call to `ReFitLevel` that moves the file back to the original level.) Before that change, a new `FileMetaData` object was created as a result of this sequence; after the change, the original `FileMetaData` was essentially resurrected (since the deletion and the addition simply cancel each other out with the change). This patch restores the original behavior, which is more intuitive considering the interface, and in sync with how trivial moves are handled. (Also note that `FileMetaData` contains some mutable data members, the values of which might be different in the resurrected object and the freshly created one.) The PR also fixes a bug in this area: with the original pre-6901 code, `VersionBuilder` would add the same file twice to the same level in the scenario described above. Pull Request resolved: facebook#6939 Test Plan: `make check` Reviewed By: ajkr Differential Revision: D21905580 Pulled By: ltamasi fbshipit-source-id: da07ae45384ecf3c6c53506d106432d88a7ec9df Signed-off-by: tabokie <xy.tao@outlook.com>

Summary: The patch cleans up the code and improves the consistency checks around adding/deleting table files in `VersionBuilder`. Namely, it makes the checks stricter and improves them in the following ways: 1) A table file can now only be deleted from the LSM tree using the level it resides on. Earlier, there was some unnecessary wiggle room for trivially moved files (they could be deleted using a lower level number than the actual one). 2) A table file cannot be added to the tree if it is already present in the tree on any level (not just the target level). The earlier code only had an assertion (which is a no-op in release builds) that the newly added file is not already present on the target level. 3) The above consistency checks around state transitions are now mandatory, as opposed to the earlier `CheckConsistencyForDeletes`, which was a no-op in release mode unless `force_consistency_checks` was set to `true`. The rationale here is that assuming that the initial state is consistent, a valid transition leads to a next state that is also consistent; however, an *invalid* transition offers no such guarantee. Hence it makes sense to validate the transitions unconditionally, and save `force_consistency_checks` for the paranoid checks that re-validate the entire state. 4) The new checks build on the mechanism introduced in facebook#6862, which enables us to efficiently look up the location (level and position within level) of files in a `Version` by file number. This makes the consistency checks much more efficient than the earlier `CheckConsistencyForDeletes`, which essentially performed a linear search. Pull Request resolved: facebook#6901 Test Plan: Extended the unit tests and ran: `make check` `make whitebox_crash_test` Reviewed By: ajkr Differential Revision: D21822714 Pulled By: ltamasi fbshipit-source-id: e2b29c8b6da1bf0f59004acc889e4870b2d18215 Signed-off-by: tabokie <xy.tao@outlook.com>

…level (facebook#6939) Summary: facebook#6901 subtly changed the handling of the corner case when a table file is deleted from a level, then re-added to the same level. (Note: this should be extremely rare; one scenario that comes to mind is a trivial move followed by a call to `ReFitLevel` that moves the file back to the original level.) Before that change, a new `FileMetaData` object was created as a result of this sequence; after the change, the original `FileMetaData` was essentially resurrected (since the deletion and the addition simply cancel each other out with the change). This patch restores the original behavior, which is more intuitive considering the interface, and in sync with how trivial moves are handled. (Also note that `FileMetaData` contains some mutable data members, the values of which might be different in the resurrected object and the freshly created one.) The PR also fixes a bug in this area: with the original pre-6901 code, `VersionBuilder` would add the same file twice to the same level in the scenario described above. Pull Request resolved: facebook#6939 Test Plan: `make check` Reviewed By: ajkr Differential Revision: D21905580 Pulled By: ltamasi fbshipit-source-id: da07ae45384ecf3c6c53506d106432d88a7ec9df Signed-off-by: tabokie <xy.tao@outlook.com>

ltamasi added 20 commits June 1, 2020 10:27

Factor out logic that applies file additions/deletions into separate …

f16ad29

…methods

Clean up ApplyFileDeletion and fold CheckConsistencyForDeletes into i…

2c2c60b

…t; extend the consistency checks and make them non-optional

Rework ApplyFileAddition and add consistency checks

ef3800e

Add comment

bcd6b23

Make sure a file can only be re-added if it has been deleted

0cfd065

Keep track of file additions/deletions per file number

8ab1db4

Keep track of the current level of touched files instead

e503c10

Rework and simplify ApplyFileAddition/ApplyFileDeletion; invalid_leve…

0d92ded

…ls_ is no longer needed, just the sizes

Add a couple of assertions, merge the two failure cases in ApplyFileD…

32f2da6

…eletion, small cleanup

Make add/delete of same file on same level cancel each other out

dab6911

Do not reuse the same Status object in Apply

3d54e5d

Use FileLocation::Invalid().GetLevel() instead of magic number -1

ebc2dba

Add error messages

862b064

More FileLocation::Invalid().GetLevel()

0eadcb8

Use emplace instead of insert

d32ae4b

Mark CheckConsistencyForNumLevels const

9478455

Fix signature of test method Add

0da4b5f

Extend unit tests

92378d3

Use size_t for the value in invalid_level_sizes_

2427289

Add a couple more tests for corner cases where a file gets added then…

48ca70a

… removed, or removed then readded

ltamasi requested a review from riversand963 June 1, 2020 18:39

facebook-github-bot added the CLA Signed label Jun 1, 2020

facebook-github-bot reviewed Jun 1, 2020

View reviewed changes

Fix unintended size_t -> int conversion

bf6883f

facebook-github-bot reviewed Jun 1, 2020

View reviewed changes

ajkr reviewed Jun 3, 2020

View reviewed changes

ajkr approved these changes Jun 3, 2020

View reviewed changes

facebook-github-bot closed this in 78e291b Jun 3, 2020

facebook-github-bot added the Merged label Jun 3, 2020

ltamasi mentioned this pull request Jun 5, 2020

Revisit the handling of the case when a file is re-added to the same level #6939

Closed

ltamasi mentioned this pull request Jun 23, 2021

Remove obsolete method VersionSet::VerifyCompactionFileConsistency #8449

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve consistency checks in VersionBuilder #6901

Improve consistency checks in VersionBuilder #6901

ltamasi commented Jun 1, 2020

facebook-github-bot left a comment

facebook-github-bot left a comment

ajkr Jun 3, 2020 •

edited

Loading

ajkr left a comment

ajkr Jun 3, 2020

ltamasi Jun 3, 2020

facebook-github-bot commented Jun 3, 2020

Improve consistency checks in VersionBuilder #6901

Improve consistency checks in VersionBuilder #6901

Conversation

ltamasi commented Jun 1, 2020

facebook-github-bot left a comment

Choose a reason for hiding this comment

facebook-github-bot left a comment

Choose a reason for hiding this comment

ajkr Jun 3, 2020 • edited Loading

Choose a reason for hiding this comment

ajkr left a comment

Choose a reason for hiding this comment

ajkr Jun 3, 2020

Choose a reason for hiding this comment

ltamasi Jun 3, 2020

Choose a reason for hiding this comment

facebook-github-bot commented Jun 3, 2020

ajkr Jun 3, 2020 •

edited

Loading