Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call ValidateOptions from SetOptions #5368

Closed

Conversation

maysamyabandeh
Copy link
Contributor

Currently we validate options in DB::Open. However the validation step is missing when options are dynamically updated in ::SetOptions. The patch fixes that.

db/db_impl.cc Outdated
env_options_for_compaction_ = env_->OptimizeForCompactionTableWrite(
env_options_for_compaction_, immutable_db_options_);
versions_->ChangeEnvOptions(mutable_db_options_);
env_options_for_compaction_ = env_->OptimizeForCompactionTableRead(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line seems to have been a mistake.

Copy link
Contributor

@sagar0 sagar0 May 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? It doesn't seem misplaced to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is introduced in #3004
Previously OptimizeForCompactionTableRead would only be used to set env_options_for_read_

env_->OptimizeForCompactionTableRead(env_options, db_options_)),
which is used for reads. env_options_for_compaction_ which is for writes should only go through OptimizeForCompactionTableWrite.
env_options_for_compaction_

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

env_options_for_compaction_ doesn't necessarily need to be for writes; at least it doesn't seem to be so from the name. I believe it is used in the lower layers to optimize compaction reads as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked all the usages. The only place it is used for read is here: https://github.com/facebook/rocksdb/blob/master/db/compaction_job.cc#L646-L652
Which explicitly says that it should not be optimized for reads.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you see OptimizeForCompactionTableRead, it sets the use_direct_reads option. If use_direct_reads is set, it impacts both user and compaction reads. All the table readers opened for either user or compaction reads should be aware of whether to use O_DIRECT or not and need to open the files appropriately.

If you follow further down the link you provided above, and see in TableCache::GetTableReader, a NewRandomAccessFile is opened with these env options.
https://github.com/facebook/rocksdb/blob/master/db/table_cache.cc#L104

And Posix's NewRandomAccessFile makes ample use of use_direct_reads:
https://github.com/facebook/rocksdb/blob/master/env/env_posix.cc#L202

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. Can you show the line that env_options_for_compaction_ is used for reading?

Moreover, env_options_for_compaction_ is not affected by OptimizeForCompactionTableRead in ::Open (which is the correct behavior) and suddenly changes when ::SetOptions is called.
If we think use_direct_reads should be used for writes (which I highly doubt), then it should be set in OptimizeForCompactionTableWrite.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed offline. Reverting the change for now to have it fixed in a later PR.

Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@facebook-github-bot
Copy link
Contributor

@maysamyabandeh has updated the pull request. Re-import the pull request

2 similar comments
@facebook-github-bot
Copy link
Contributor

@maysamyabandeh has updated the pull request. Re-import the pull request

@facebook-github-bot
Copy link
Contributor

@maysamyabandeh has updated the pull request. Re-import the pull request

Copy link
Contributor

@sagar0 sagar0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change looks reasonable to me.
I'll take a deeper look tomorrow to make sure that all the cases are being handled.

@facebook-github-bot
Copy link
Contributor

@maysamyabandeh has updated the pull request. Re-import the pull request

1 similar comment
@facebook-github-bot
Copy link
Contributor

@maysamyabandeh has updated the pull request. Re-import the pull request

Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@sagar0 sagar0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The overall flow looks good to me. Just a few comments.

db/db_impl.cc Outdated
env_options_for_compaction_ = env_->OptimizeForCompactionTableWrite(
env_options_for_compaction_, immutable_db_options_);
versions_->ChangeEnvOptions(mutable_db_options_);
env_options_for_compaction_ = env_->OptimizeForCompactionTableRead(
Copy link
Contributor

@sagar0 sagar0 May 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? It doesn't seem misplaced to me.

db/db_impl.cc Outdated
}
DBOptions new_db_options =
BuildDBOptions(immutable_db_options_, new_options);
if (s.ok()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lines 919-920 (maybe lines 916-917 too) should also be inside s.ok(), as there is no reason to call BuildDBOptions if GetMutableDBOptionsFromStrings itself has failed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be less optimized. new_db_options has to be outside s.ok() clause so that it could be reused below. However if we separate the declaration from assignment, the compiler might create two option object: 1st with default values, and 2nd when it is assigned. Assuming at SetOptions mostly pass through, this way is more optimized.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that makes sense. Thanks!

db/db_impl.cc Outdated
@@ -912,6 +913,25 @@ Status DBImpl::SetDBOptions(
InstrumentedMutexLock l(&mutex_);
s = GetMutableDBOptionsFromStrings(mutable_db_options_, options_map,
&new_options);
if (new_options.bytes_per_sync == 0) {
new_options.bytes_per_sync = 1024 * 1024;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious, why change it from the place where it was earlier? Why does this need to be done before BuildDBOptions ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously there was only one BuildDBOptions at line 964. Now that we have two, I optimized it for the 2nd to use the result of the 1st. For the however there should not be any change between the two. Updating bytes_per_sync was the only such change, so I moved it before the 1st BuildDBOptions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where's the second BuildDBOptions? I see only one on line 920. Maybe I missed the other one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I thought you were saying there are two calls to BuildDBOptions in the new code.

@facebook-github-bot
Copy link
Contributor

@maysamyabandeh has updated the pull request. Re-import the pull request

remove redudant BuildDBOptions

remove mistaken OptimizeForCompactionTableRead on write options

ValidateOptions in SetOptions

make format

return correct status

exclude invalids from random options

minor

Disable setting snappy option in Appveyor

exclude unsupported compression types from random gen

put back OptimizeForCompactionTableRead
@facebook-github-bot
Copy link
Contributor

@maysamyabandeh has updated the pull request. Re-import the pull request

Copy link
Contributor

@sagar0 sagar0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. lgtm.

Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maysamyabandeh is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

@facebook-github-bot
Copy link
Contributor

@maysamyabandeh merged this pull request in ae05a83.

facebook-github-bot pushed a commit that referenced this pull request Jun 11, 2019
…5438)

Summary:
This affects our "no compression" automated tests. Since PR #5368, DBTest.DynamicMiscOptions has been failing with:

db/db_test.cc:4889: Failure
dbfull()->SetOptions({{"compression", "kSnappyCompression"}})
Invalid argument: Compression type Snappy is not linked with the binary.
Pull Request resolved: #5438

Differential Revision: D15752100

Pulled By: ltamasi

fbshipit-source-id: 3f19eff7cafc03b333965be0203c5853d2a9cb71
vagogte pushed a commit to vagogte/rocksdb that referenced this pull request Jun 18, 2019
Summary:
Currently we validate options in DB::Open. However the validation step is missing when options are dynamically updated in ::SetOptions. The patch fixes that.
Pull Request resolved: facebook#5368

Differential Revision: D15540101

Pulled By: maysamyabandeh

fbshipit-source-id: d27bbffd8f0252d1b50bcf59e0a70a278ed937f4
vagogte pushed a commit to vagogte/rocksdb that referenced this pull request Jun 18, 2019
…acebook#5438)

Summary:
This affects our "no compression" automated tests. Since PR facebook#5368, DBTest.DynamicMiscOptions has been failing with:

db/db_test.cc:4889: Failure
dbfull()->SetOptions({{"compression", "kSnappyCompression"}})
Invalid argument: Compression type Snappy is not linked with the binary.
Pull Request resolved: facebook#5438

Differential Revision: D15752100

Pulled By: ltamasi

fbshipit-source-id: 3f19eff7cafc03b333965be0203c5853d2a9cb71
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants