1. 24 2月, 2021 1 次提交
    • S
      Extract test cases correctly in run_ci_db_test.ps1 script (#7989) · f91fd0c9
      sherriiiliu 提交于
      Summary:
      Extract test cases correctly in run_ci_db_test.ps1 script.
      
      There are some new test group that are ended with # comments. Previously in the script when trying to extract test groups and test cases, the regex rule did not apply to this case so the concatenation of some test group and test case failed, see examples in comments.
      
      Also removed useless trailing whitespaces in the script.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7989
      
      Reviewed By: jay-zhuang
      
      Differential Revision: D26615909
      
      Pulled By: ajkr
      
      fbshipit-source-id: 8e68d599994f17d6fefde0daa925c3018179521a
      f91fd0c9
  2. 23 2月, 2021 2 次提交
  3. 22 2月, 2021 1 次提交
    • M
      Attempt to speed up tests by adding test to "slow" tests (#7973) · 59d91796
      mrambacher 提交于
      Summary:
      I noticed tests frequently timing out on CircleCI when I submit a PR.  I did some investigation and found the SeqAdvanceConcurrentTest suite (OneWriteQueue, TwoWriteQueues) tests were all taking a long time to complete (30 tests each taking at least 15K ms).
      
      This PR adds those test to the "slow reg" list in order to move them earlier in the execution sequence so that they are not the "long tail".
      
      For completeness, other tests that were also slow are:
      NumLevels/DBTestUniversalCompaction.UniversalCompactionTrivialMoveTest : 12 tests all taking 12K+ ms
      ReadSequentialFileTest with ReadaheadSize: 8 tests all 12K+ ms
      WriteUnpreparedTransactionTest.RecoveryTest : 2 tests at 22K+ ms
      DBBasicTest.EmptyFlush: 1 test at 35K+ ms
      RateLimiterTest.Rate: 1 test at 23K+ ms
      BackupableDBTest.ShareTableFilesWithChecksumsTransition: 1 test at 16K+ ms
      MulitThreadedDBTest.MultitThreaded: 78 tests at 10K+ ms
      TransactionStressTest.DeadlockStress: 7 tests at 11K+ ms
      DBBasicTestDeadline.IteratorDeadline: 3 tests at 10K+ ms
      
      No effort was made to determine why the tests were slow.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7973
      
      Reviewed By: jay-zhuang
      
      Differential Revision: D26519130
      
      Pulled By: mrambacher
      
      fbshipit-source-id: 11555c9115acc207e45e210a7fc7f879170a3853
      59d91796
  4. 21 2月, 2021 1 次提交
  5. 20 2月, 2021 5 次提交
    • Y
      Update HISTORY and bump version (#7984) · 7343eb4a
      Yanqin Jin 提交于
      Summary:
      Prepare to cut 6.18.fb branch
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7984
      
      Reviewed By: ajkr
      
      Differential Revision: D26557151
      
      Pulled By: riversand963
      
      fbshipit-source-id: 8c144c807090cdae67e6655e7a17056ce8c50bc0
      7343eb4a
    • A
      Limit buffering for collecting samples for compression dictionary (#7970) · d904233d
      Andrew Kryczka 提交于
      Summary:
      For dictionary compression, we need to collect some representative samples of the data to be compressed, which we use to either generate or train (when `CompressionOptions::zstd_max_train_bytes > 0`) a dictionary. Previously, the strategy was to buffer all the data blocks during flush, and up to the target file size during compaction. That strategy allowed us to randomly pick samples from as wide a range as possible that'd be guaranteed to land in a single output file.
      
      However, some users try to make huge files in memory-constrained environments, where this strategy can cause OOM. This PR introduces an option, `CompressionOptions::max_dict_buffer_bytes`, that limits how much data blocks are buffered before we switch to unbuffered mode (which means creating the per-SST dictionary, writing out the buffered data, and compressing/writing new blocks as soon as they are built). It is not strict as we currently buffer more than just data blocks -- also keys are buffered. But it does make a step towards giving users predictable memory usage.
      
      Related changes include:
      
      - Changed sampling for dictionary compression to select unique data blocks when there is limited availability of data blocks
      - Made use of `BlockBuilder::SwapAndReset()` to save an allocation+memcpy when buffering data blocks for building a dictionary
      - Changed `ParseBoolean()` to accept an input containing characters after the boolean. This is necessary since, with this PR, a value for `CompressionOptions::enabled` is no longer necessarily the final component in the `CompressionOptions` string.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7970
      
      Test Plan:
      - updated `CompressionOptions` unit tests to verify limit is respected (to the extent expected in the current implementation) in various scenarios of flush/compaction to bottommost/non-bottommost level
      - looked at jemalloc heap profiles right before and after switching to unbuffered mode during flush/compaction. Verified memory usage in buffering is proportional to the limit set.
      
      Reviewed By: pdillinger
      
      Differential Revision: D26467994
      
      Pulled By: ajkr
      
      fbshipit-source-id: 3da4ef9fba59974e4ef40e40c01611002c861465
      d904233d
    • M
      Avoid self-move-assign in pop operation of binary heap. (#7942) · cf14cb3e
      Max Neunhoeffer 提交于
      Summary:
      The current implementation of a binary heap in `util/heap.h` does a move-assign in the `pop` method. In the case that there is exactly one element stored in the heap, this ends up being a self-move-assign. This can cause trouble with certain classes, which are not prepared for this. Furthermore, it trips up the glibc STL debugger (`-D_GLIBCXX_DEBUG`), which produces an assertion failure in this case.
      
      This PR addresses this problem by not doing the (unnecessary in this case) move-assign if there is only one element in the heap.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7942
      
      Reviewed By: jay-zhuang
      
      Differential Revision: D26528739
      
      Pulled By: ajkr
      
      fbshipit-source-id: 5ca570e0c4168f086b10308ad766dff84e6e2d03
      cf14cb3e
    • T
      gitignore cmake-build-* for CLion integration (#7933) · ec76f031
      tison 提交于
      Summary: Pull Request resolved: https://github.com/facebook/rocksdb/pull/7933
      
      Reviewed By: jay-zhuang
      
      Differential Revision: D26529429
      
      Pulled By: ajkr
      
      fbshipit-source-id: 244344b70b1db161f9b224c25fe690c663264d7d
      ec76f031
    • M
      Fix handling of Mutable options; Allow DB::SetOptions to update mutable... · 4bc9df94
      mrambacher 提交于
      Fix handling of Mutable options; Allow DB::SetOptions to update mutable TableFactory Options (#7936)
      
      Summary:
      Added a "only_mutable_options" flag to the ConfigOptions.  When set, the Configurable methods will only look at/update options that are marked as kMutable.
      
      Fixed DB::SetOptions to allow for the update of any mutable TableFactory options.  Fixes https://github.com/facebook/rocksdb/issues/7385.
      
      Added tests for the new flag.  Updated HISTORY.md
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7936
      
      Reviewed By: akankshamahajan15
      
      Differential Revision: D26389646
      
      Pulled By: mrambacher
      
      fbshipit-source-id: 6dc247f6e999fa2814059ebbd0af8face109fea0
      4bc9df94
  6. 19 2月, 2021 9 次提交
  7. 18 2月, 2021 3 次提交
    • A
      Bug fix for status overridden by Status::NotFound in db_impl_readonly (#7972) · 6a85aea5
      Akanksha Mahajan 提交于
      Summary:
      Bug fix for status returned being overridden by Status::NotFound in
      DBImpl::OpenForReadOnlyCheckExistence. This was casuing some service
      owners to misinterpret the actual error and take appropriate steps.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7972
      
      Reviewed By: riversand963
      
      Differential Revision: D26499598
      
      Pulled By: akankshamahajan15
      
      fbshipit-source-id: 05e9fedbe2a2e0e53135760f8ff578a2816d2b8e
      6a85aea5
    • L
      Add checkpoint support to BlobDB (#7959) · dab4fe5b
      Levi Tamasi 提交于
      Summary:
      The patch adds checkpoint support to BlobDB. Blob files are hard linked or
      copied, depending on whether the checkpoint directory is on the same filesystem
      or not, similarly to table files.
      
      TODO: Add support for blob files to `ExportColumnFamily` and to the checksum
      verification logic used by backup/restore.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7959
      
      Test Plan: Ran `make check` and the crash test for a while.
      
      Reviewed By: riversand963
      
      Differential Revision: D26434768
      
      Pulled By: ltamasi
      
      fbshipit-source-id: 994be55a8dc08133028250760fca440d2c7c4dc5
      dab4fe5b
    • L
      Add support for the integrated BlobDB to db_bench (#7956) · 0743eba0
      Levi Tamasi 提交于
      Summary:
      The patch adds the configuration options of the new BlobDB implementation
      to `db_bench` and adjusts the help messages of the old (`StackableDB`-based)
      BlobDB's options to make it clear which implementation they pertain to.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7956
      
      Test Plan: Ran `make check` and `db_bench` with the new options.
      
      Reviewed By: jay-zhuang
      
      Differential Revision: D26384808
      
      Pulled By: ltamasi
      
      fbshipit-source-id: b4405bb2c56cfd3506d4c32e3329c08dfdf69c94
      0743eba0
  8. 17 2月, 2021 2 次提交
  9. 16 2月, 2021 1 次提交
  10. 12 2月, 2021 1 次提交
  11. 11 2月, 2021 6 次提交
    • Z
      Handoff checksum Implementation (#7523) · d1c510ba
      Zhichao Cao 提交于
      Summary:
      in PR https://github.com/facebook/rocksdb/issues/7419 , we introduce the new Append and PositionedAppend APIs to WritableFile at File System, which enable RocksDB to pass the data verification information (e.g., checksum of the data) to the lower layer. In this PR, we use the new API in WritableFileWriter, such that the file created via WritableFileWrite can pass the checksum to the storage layer. To control which types file should apply the checksum handoff, we add checksum_handoff_file_types to DBOptions. User can use this option to control which file types (Currently supported file tyes: kLogFile, kTableFile, kDescriptorFile.) should use the new Append and PositionedAppend APIs to handoff the verification information.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7523
      
      Test Plan: add new unit test, pass make check/ make asan_check
      
      Reviewed By: pdillinger
      
      Differential Revision: D24313271
      
      Pulled By: zhichao-cao
      
      fbshipit-source-id: aafd69091ae85c3318e3e17cbb96fe7338da11d0
      d1c510ba
    • P
      Add prefetching (batched MultiGet) for experimental Ribbon filter (#7889) · e4f1e64c
      Peter Dillinger 提交于
      Summary:
      Adds support for prefetching data in Ribbon queries,
      which especially optimizes batched Ribbon queries for MultiGet
      (~222ns/key to ~97ns/key) but also single key queries on cold memory
      (~333ns to ~226ns) because many queries span more than one cache line.
      
      This required some refactoring of the query algorithm, and there
      does not appear to be a noticeable regression in "hot memory" query
      times (perhaps from 48ns to 50ns).
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7889
      
      Test Plan:
      existing unit tests, plus performance validation with
      filter_bench:
      
      Each data point is the best of two runs. I saturated the machine
      CPUs with other filter_bench runs in the background.
      
      Before:
      
          $ ./filter_bench -impl=3 -m_keys_total_max=200 -average_keys_per_filter=100000 -m_queries=50
          WARNING: Assertions are enabled; benchmarks unnecessarily slow
          Building...
          Build avg ns/key: 125.86
          Number of filters: 1993
          Total size (MB): 168.166
          Reported total allocated memory (MB): 183.211
          Reported internal fragmentation: 8.94626%
          Bits/key stored: 7.05341
          Prelim FP rate %: 0.951827
          ----------------------------
          Mixed inside/outside queries...
            Single filter net ns/op: 48.0111
            Batched, prepared net ns/op: 222.384
            Batched, unprepared net ns/op: 343.908
            Skewed 50% in 1% net ns/op: 252.916
            Skewed 80% in 20% net ns/op: 320.579
            Random filter net ns/op: 332.957
      
      After:
      
          $ ./filter_bench -impl=3 -m_keys_total_max=200 -average_keys_per_filter=100000 -m_queries=50
          WARNING: Assertions are enabled; benchmarks unnecessarily slow
          Building...
          Build avg ns/key: 128.117
          Number of filters: 1993
          Total size (MB): 168.166
          Reported total allocated memory (MB): 183.211
          Reported internal fragmentation: 8.94626%
          Bits/key stored: 7.05341
          Prelim FP rate %: 0.951827
          ----------------------------
          Mixed inside/outside queries...
            Single filter net ns/op: 49.8812
            Batched, prepared net ns/op: 97.1514
            Batched, unprepared net ns/op: 222.025
            Skewed 50% in 1% net ns/op: 197.48
            Skewed 80% in 20% net ns/op: 212.457
            Random filter net ns/op: 226.464
      
      Bloom comparison, for reference:
      
          $ ./filter_bench -impl=2 -m_keys_total_max=200 -average_keys_per_filter=100000 -m_queries=50
          WARNING: Assertions are enabled; benchmarks unnecessarily slow
          Building...
          Build avg ns/key: 35.3042
          Number of filters: 1993
          Total size (MB): 238.488
          Reported total allocated memory (MB): 262.875
          Reported internal fragmentation: 10.2255%
          Bits/key stored: 10.0029
          Prelim FP rate %: 0.965327
          ----------------------------
          Mixed inside/outside queries...
            Single filter net ns/op: 9.09931
            Batched, prepared net ns/op: 34.21
            Batched, unprepared net ns/op: 88.8564
            Skewed 50% in 1% net ns/op: 139.75
            Skewed 80% in 20% net ns/op: 181.264
            Random filter net ns/op: 173.88
      
      Reviewed By: jay-zhuang
      
      Differential Revision: D26378710
      
      Pulled By: pdillinger
      
      fbshipit-source-id: 058428967c55ed763698284cd3b4bbe3351b6e69
      e4f1e64c
    • D
      db_bench: dump cpu info for Mac. (#7932) · 14fbb43f
      David CARLIER 提交于
      Summary: Pull Request resolved: https://github.com/facebook/rocksdb/pull/7932
      
      Reviewed By: jay-zhuang
      
      Differential Revision: D26316480
      
      Pulled By: zhichao-cao
      
      fbshipit-source-id: 3e002e49fcb7f60bc9270550a6b3e182fe197551
      14fbb43f
    • X
      Build a full RocksDB on M1 macs (#7943) · 7ebde3da
      Xavier Deguillard 提交于
      Summary:
      With M1 macs being available, it is possible that RocksDB will be built on them, without the resulting artifacts to be intended for iOS, where a non-lite RocksDB is needed.
      
      It is not clear to me why the ROCKSDB_LITE cmake option isn't used for iOS consumer, so sending this pull request as a way to foster discussion and to find a path forward to get a full RocksDB build on M1.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7943
      
      Test Plan:
      Applied the following patch:
      ```
       diff --git a/fbcode/opensource/fbcode_builder/manifests/rocksdb b/fbcode/opensource/fbcode_builder/manifests/rocksdb
       --- a/fbcode/opensource/fbcode_builder/manifests/rocksdb
      +++ b/fbcode/opensource/fbcode_builder/manifests/rocksdb
      @@ -2,8 +2,8 @@
       name = rocksdb
      
       [download]
      -url = https://github.com/facebook/rocksdb/archive/v6.8.1.tar.gz
      -sha256 = ca192a06ed3bcb9f09060add7e9d0daee1ae7a8705a3d5ecbe41867c5e2796a2
      +url = https://github.com/xavierd/rocksdb/archive/master.zip
      +sha256 = f93f3f92df66a8401659e35398749d5910b92bd9c14b8354a35ea8852865c422
      
       [dependencies]
       lz4
      @@ -11,7 +11,7 @@
      
       [build]
       builder = cmake
      -subdir = rocksdb-6.8.1
      +subdir = rocksdb-master
      
       [cmake.defines]
       WITH_SNAPPY=ON
      ```
      
      And ran `getdeps build eden` on an M1 macbook. The build used to fail at link time due to some RocksDB symbols not being found, it now fails for another reason (x86_64 Rust symbols).
      
      Reviewed By: jay-zhuang
      
      Differential Revision: D26324049
      
      Pulled By: xavierd
      
      fbshipit-source-id: 12d86f3395709c4c323f440844e3ae65672aef2d
      7ebde3da
    • Y
      Use actual url instead of tinyurl.com (#7950) · 170dffac
      Yanqin Jin 提交于
      Summary:
      Due to offline discussion, we use actual url of the clang-format-diff.py and add a note.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7950
      
      Reviewed By: pdillinger
      
      Differential Revision: D26370822
      
      Pulled By: riversand963
      
      fbshipit-source-id: 7508e23c002d56d5c1649090438ef5f8ff2cdbe7
      170dffac
    • A
      Makefile support to statically link external plugin code (#7918) · c16d5a4f
      Andrew Kryczka 提交于
      Summary:
      Added support for detecting plugins linked in the "plugin/" directory and building them from our Makefile in a standardized way. See "plugin/README.md" for details. An example of a plugin that can be built in this way can be found in https://github.com/ajkr/dedupfs.
      
      There will be more to do in terms of making this process more convenient and adding support for CMake.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7918
      
      Test Plan: my own plugin (https://github.com/ajkr/dedupfs) and also heard this patch worked with ZenFS.
      
      Reviewed By: pdillinger
      
      Differential Revision: D26189969
      
      Pulled By: ajkr
      
      fbshipit-source-id: 6624d4357d0ffbaedb42f0d12a3fcb737c78f758
      c16d5a4f
  12. 10 2月, 2021 2 次提交
  13. 09 2月, 2021 2 次提交
  14. 07 2月, 2021 1 次提交
  15. 06 2月, 2021 3 次提交
    • S
      Stress test to allow memtable whole key filter (#7937) · e3183eae
      sdong 提交于
      Summary:
      Right now, stress test cannot be configured to use memtable whole key filter without prefix filter. It doesn't appear to be necessary. remove this constraint.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7937
      
      Test Plan: "make crash_test" to be able to run.
      
      Reviewed By: ltamasi
      
      Differential Revision: D26295532
      
      fbshipit-source-id: 30c874a9dc2b672a460603a4ee32368674e0face
      e3183eae
    • A
      Allow range deletions in `*TransactionDB` only when safe (#7929) · 8d2bbdd0
      Andrew Kryczka 提交于
      Summary:
      Explicitly reject all range deletions on `TransactionDB` or `OptimisticTransactionDB`, except when the user provides sufficient promises that allow us to proceed safely. The necessary promises are described in the API doc for `TransactionDB::DeleteRange()`. There is currently no way to provide enough promises to make it safe in `OptimisticTransactionDB`.
      
      Fixes https://github.com/facebook/rocksdb/issues/7913.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7929
      
      Test Plan: unit tests covering the cases it's permitted/rejected
      
      Reviewed By: ltamasi
      
      Differential Revision: D26240254
      
      Pulled By: ajkr
      
      fbshipit-source-id: 2834a0ce64cc3e4c3799e35b885a5e79c2f4f6d9
      8d2bbdd0
    • L
      Fix db_bench_tool_test (#7935) · 4fba83b4
      Levi Tamasi 提交于
      Summary:
      The patch fixes the build for `db_bench_tool_test` and makes the tests pass.
      Namely, it fixes the following issues:
      
      * https://github.com/facebook/rocksdb/issues/7703 removed the member variable `fs_` but the test case `OptionsFileMultiLevelUniversal`
      was not updated.
      * https://github.com/facebook/rocksdb/issues/7344 fixed the `OptionsFile` test case for the case when Snappy is *not* available but at the
      same time broke it for the case when it *is* available. (The test used a default-constructed
      `ColumnFamilyOptions` object, and the default value of the `compression` option is either
      Snappy or no compression depending on whether Snappy is supported.)
      * The test used `google::ParseCommandLineFlags` instead of
      `GFLAGS_NAMESPACE::ParseCommandLineFlags`.
      
      Pull Request resolved: https://github.com/facebook/rocksdb/pull/7935
      
      Test Plan: Ran the test both with and without Snappy support.
      
      Reviewed By: zhichao-cao
      
      Differential Revision: D26269765
      
      Pulled By: ltamasi
      
      fbshipit-source-id: b7303d8a981ab299d22ab540e0cbd12d149ed9bb
      4fba83b4