dolysis
/
rocksdb
mirror of https://github.com/facebook/rocksdb.git
3
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Disable uncache_aggressiveness with allow_mmap_reads (#13051) 

Summary:
There was a crash test Bus Error crash in `IndexBlockIter::SeekToFirstImpl()` <- .. <-
`BlockBasedTable::~BlockBasedTable()` with `--mmap_read=1`, which suggests some kind of incompatibility that I haven't diagnosed. Bus Error is uncommon these days as CPUs support unaligned reads, but are associated with mmap problems.

Because mmap reads really only make sense without block cache, it's not a concerning loss to essentially disable the combination.

Pull Request resolved: https://github.com/facebook/rocksdb/pull/13051

Test Plan: watch crash test

Reviewed By: jowlyzhang

Differential Revision: D63795069

Pulled By: pdillinger

fbshipit-source-id: 6c823c619840086b5c9cff53dbc7470662b096be
This commit is contained in:
Peter Dillinger 2024-10-02 18:16:50 -07:00 committed by Facebook GitHub Bot
parent 9375c3b635
commit 12960f0b57
2 changed files with 9 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
include/rocksdb/options.h
View File

@ -388,6 +388,8 @@ struct ColumnFamilyOptions : public AdvancedColumnFamilyOptions {
// block cache entries (shared among copies) are obsolete. Such a scenerio
// is the best case for uncache_aggressiveness = 0.
//
// When using allow_mmap_reads=true, this option is ignored (no un-caching).
//
// Once validated in production, the default will likely change to something
// around 300.
uint32_t uncache_aggressiveness = 0;

8
table/block_based/block_based_table_reader.cc
View File

@ -137,7 +137,13 @@ extern const std::string kHashIndexPrefixesMetadataBlock;
BlockBasedTable::~BlockBasedTable() {
auto ua = rep_->uncache_aggressiveness.LoadRelaxed();
if (ua > 0 && rep_->table_options.block_cache) {
// NOTE: there is an undiagnosed incompatibility with mmap reads,
// where attempting to read the index below can result in bus error.
// In theory the mmap should remain in place until destruction of
// rep_, so even a page fault should be satisfiable. But also, combining
// mmap reads with block cache is weird, so it's not a concerning loss.
if (ua > 0 && rep_->table_options.block_cache &&
!rep_->ioptions.allow_mmap_reads) {
if (rep_->filter) {
rep_->filter->EraseFromCacheBeforeDestruction(ua);
}