1. 15 5月, 2014 9 次提交
  2. 14 5月, 2014 7 次提交
    • Y
    • Y
      [Java] Refined the output of Java DbBenchmark. · e883407e
      Yueh-Hsuan Chiang 提交于
      e883407e
    • S
      FixedPrefixTransform to include prefix length in its name · 8c2c4602
      sdong 提交于
      Summary: As title
      
      Test Plan: make all check.
      
      Reviewers: haobo, igor, yhchiang
      
      Reviewed By: igor
      
      CC: leveldb
      
      Differential Revision: https://reviews.facebook.net/D18705
      8c2c4602
    • Y
      [Java] Fixed a bug in Java DB Benchmark where random reads does not consider full key range. · e30dec93
      Yueh-Hsuan Chiang 提交于
      Summary: Fixed a bug in Java DB Benchmark where random reads does not consider full key range.
      
      Test Plan:
      make rocksdbjava
      make jdb_bench
      cd java
      jdb_bench.sh --db=/tmp/rocksdb-test --benchmarks=fillseq --use_existing_db=false --num=100000
      jdb_bench.sh --db=/tmp/rocksdb-test --benchmarks=readrandom --use_existing_db=true --num=100000 --reads=1000000
      
      Reviewers: haobo, sdong
      
      Reviewed By: haobo
      
      CC: leveldb
      
      Differential Revision: https://reviews.facebook.net/D18693
      e30dec93
    • Y
      [Java] Make read benchmarks print out found / not-found information. · 93f26436
      Yueh-Hsuan Chiang 提交于
      Summary: Make read benchmarks print out found / not-found information.
      
      Test Plan:
      make rocksdbjava
      make jdb_bench
      cd java
      ./jdb_bench.sh
      
      Reviewers: haobo, sdong
      
      CC: leveldb
      
      Differential Revision: https://reviews.facebook.net/D18699
      93f26436
    • I
      TablePropertiesCollectorFactory · 26f5dd9a
      Igor Canadi 提交于
      Summary:
      This diff addresses task #4296714 and rethinks how users provide us with TablePropertiesCollectors as part of Options.
      
      Here's description of task #4296714:
             I'm debugging #4295529 and noticed that our count of user properties kDeletedKeys is wrong. We're sharing one single InternalKeyPropertiesCollector with all Table Builders. In LOG Files, we're outputting number of kDeletedKeys as connected with a single table, while it's actually the total count of deleted keys since creation of the DB.
      
             For example, this table has 3155 entries and 1391828 deleted keys.
      
      The problem with current approach that we call methods on a single TablePropertiesCollector for all the tables we create. Even worse, we could do it from multiple threads at the same time and TablePropertiesCollector has no way of knowing which table we're calling it for.
      
      Good part: Looks like nobody inside Facebook is using Options::table_properties_collectors. This means we should be able to painfully change the API.
      
      In this change, I introduce TablePropertiesCollectorFactory. For every table we create, we call `CreateTablePropertiesCollector`, which creates a TablePropertiesCollector for a single table. We then use it sequentially from a single thread, which means it doesn't have to be thread-safe.
      
      Test Plan:
      Added a test in table_properties_collector_test that fails on master (build two tables, assert that kDeletedKeys count is correct for the second one).
      Also, all other tests
      
      Reviewers: sdong, dhruba, haobo, kailiu
      
      Reviewed By: kailiu
      
      CC: leveldb
      
      Differential Revision: https://reviews.facebook.net/D18579
      26f5dd9a
    • Y
      [Java] Temporary set the number of BG threads based on the number of BG compactions. · 2082a7d7
      Yueh-Hsuan Chiang 提交于
      Summary:
      Before the Java binding for Env is ready, Java developers have no way to
      control the number of background threads.  This diff provides a temporary
      solution where RocksDB.setMaxBackgroundCompactions() will affect the
      number of background threads.
      
      Note that once Env is ready.  Changes made in this diff should be reverted.
      
      Test Plan:
      make rocksdbjava
      make jtest
      make jdb_bench
      java/jdb_bench.sh
      
      Reviewers: haobo, sdong
      
      Reviewed By: sdong
      
      CC: leveldb
      
      Differential Revision: https://reviews.facebook.net/D18681
      2082a7d7
  3. 13 5月, 2014 3 次提交
  4. 12 5月, 2014 1 次提交
  5. 11 5月, 2014 5 次提交
  6. 10 5月, 2014 3 次提交
  7. 09 5月, 2014 6 次提交
  8. 08 5月, 2014 4 次提交
    • D
      remove anon mmap allocation flag `MAP_HUGETLB` · f41cde31
      dallas marlow 提交于
      f41cde31
    • I
      Fix iOS compile · b5616daf
      Igor Canadi 提交于
      b5616daf
    • I
      [fix] SIGSEGV when VersionEdit in MANIFEST is corrupted · 768d424d
      Igor Canadi 提交于
      Summary:
      This was reported by our customers in task #4295529.
      
      Cause:
      * MANIFEST file contains a VersionEdit, which contains file entries whose 'smallest' and 'largest' internal keys are empty. String with zero characters. Root cause of corruption was not investigated. We should report corruption when this happens. However, we currently SIGSEGV.
      
      Here's what happens:
      * VersionEdit encodes zero-strings happily and stores them in smallest and largest InternalKeys. InternalKey::Encode() does assert when `rep_.empty()`, but we don't assert in production environemnts. Also, we should never assert as a result of DB corruption.
      * As part of our ConsistencyCheck, we call GetLiveFilesMetaData()
      * GetLiveFilesMetadata() calls `file->largest.user_key().ToString()`
      * user_key() function does: 1. assert(size > 8) (ooops, no assert), 2. returns `Slice(internal_key.data(), internal_key.size() - 8)`
      * since `internal_key.size()` is unsigned int, this call translates to `Slice(whatever, 1298471928561892576182756)`. Bazinga.
      
      Fix:
      * VersionEdit checks if InternalKey is valid in `VersionEdit::GetInternalKey()`. If it's invalid, returns corruption.
      
      Lessons learned:
      * Always keep in mind that even if you `assert()`, production code will continue execution even if assert fails.
      * Never `assert` based on DB corruption. Assert only if the code should guarantee that assert can't fail.
      
      Test Plan: dumped offending manifest. Before: assert. Now: corruption
      
      Reviewers: dhruba, haobo, sdong
      
      Reviewed By: dhruba
      
      CC: leveldb
      
      Differential Revision: https://reviews.facebook.net/D18507
      768d424d
    • I
      Better INSTALL.md and Makefile rules · 313b2e5d
      Igor Canadi 提交于
      Summary: We have a lot of problems with gflags. However, when compiling rocksdb static library, we don't need gflags dependency. Reorganize INSTALL.md such that first-time customers don't need any dependency installed to actually build rocksdb static library.
      
      Test Plan: none
      
      Reviewers: dhruba, haobo
      
      Reviewed By: dhruba
      
      CC: leveldb
      
      Differential Revision: https://reviews.facebook.net/D18501
      313b2e5d
  9. 07 5月, 2014 1 次提交
    • S
      fsync directory after creating current file in NewDB() · 9efbd85a
      sdong 提交于
      Summary: One of our users reported current file corruption. The machine was rebooted during the time. This is the only think I can think of which could cause current file corruption. Just add this paranoid check.
      
      Test Plan: make all check
      
      Reviewers: haobo, igor
      
      Reviewed By: haobo
      
      CC: yhchiang, dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D18495
      9efbd85a
  10. 06 5月, 2014 1 次提交