1. 13 5月, 2016 2 次提交
  2. 12 5月, 2016 3 次提交
  3. 11 5月, 2016 9 次提交
    • A
      Isolate db env and backup Env in unit tests · e61ba052
      Andrew Kryczka 提交于
      Summary:
      - Used ChrootEnv so the database and backup Envs are isolated in the filesystem.
      - Removed DifferentEnvs test since now every test uses different Envs
      
      Depends on D57543
      
      Test Plan:
      - ran backupable_db_test
      - verified backupable_db_test now catches the bug when D57159 is backed out (this bug previously passed through the test cases, which motivated this change)
      
      Reviewers: sdong, lightmark, IslamAbdelRahman
      
      Reviewed By: IslamAbdelRahman
      
      Subscribers: andrewkr, dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D57615
      e61ba052
    • I
      Fix data race in GetObsoleteFiles() · 560358dc
      Islam AbdelRahman 提交于
      Summary:
      GetObsoleteFiles() and LogAndApply() functions modify obsolete_manifests_ vector
      we need to make sure that the mutex is held when we modify the obsolete_manifests_
      
      Test Plan: run the test under TSAN
      
      Reviewers: andrewkr
      
      Reviewed By: andrewkr
      
      Subscribers: andrewkr, dhruba
      
      Differential Revision: https://reviews.facebook.net/D58011
      560358dc
    • A
      ldb option for compression dictionary size · 5c1c9048
      Andrew Kryczka 提交于
      Summary:
      Expose the option so it's easy to run offline tests of compression
      dictionary feature.
      
      Test Plan:
      verified compression dictionary is loaded into lz4 for below command:
      
        $ ./ldb compact --compression_type=lz4 --compression_max_dict_bytes=16384 --db=/tmp/feed-compression-test/
      
      Reviewers: IslamAbdelRahman, sdong
      
      Reviewed By: sdong
      
      Subscribers: andrewkr, dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D57441
      5c1c9048
    • R
      [rocksdb] 2PC double recovery bug fix · c27061da
      Reid Horuff 提交于
      Summary:
      1. prepare()
      2. crash
      3. recover
      4. commit()
      5. crash
      6. data is lost
      
      This is due to the transaction data still only residing in the WAL but because the logs were flushed on the first recovery the data is ignored on the second recovery. We must scan all logs found on recovery and only ignore redundant data at the time of replay. It is not possible to know which logs still contain relevant data at time of recovery. We cannot simply ignore a log because all of the non-2pc data it contains has already been written to L0.
      
      The changes made to MemTableInserter are to ensure that prepared sections are still recovered even if all of the non-2pc data in that log has already been flushed to L0.
      
      Test Plan: Provided test.
      
      Reviewers: sdong
      
      Subscribers: andrewkr, hermanlee4, dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D57729
      c27061da
    • R
      [rocksdb] Recovery path sequence miscount fix · a657ee9a
      Reid Horuff 提交于
      Summary:
      Consider the following WAL with 4 batch entries prefixed with their sequence at time of memtable insert.
      [1: BEGIN_PREPARE, PUT, PUT, PUT, PUT, END_PREPARE(a)]
      [1: BEGIN_PREPARE, PUT, PUT, PUT, PUT, END_PREPARE(b)]
      [4: COMMIT(a)]
      [7: COMMIT(b)]
      
      The first two batches do not consume any sequence numbers so are both prefixed with seq=1.
      For 2pc commit, memtable insertion takes place before COMMIT batch is written to WAL.
      We can see that sequence number consumption takes place between WAL entries giving us the seemingly sparse sequence prefix for WAL entries.
      This is a valid WAL.
      
      Because with 2PC markers one WriteBatch points to another batch containing its inserts a writebatch can consume more or less sequence numbers than the number of sequence consuming entries that it contains.
      
      We can see that, given the entries in the WAL, 6 sequence ids were consumed. Yet on recovery the maximum sequence consumed would be 7 + 3 (the number of sequence numbers consumed by COMMIT(b))
      
      So, now upon recovery we must track the actual consumption of sequence numbers.
      In the provided scenario there will be no sequence gaps, but it is possible to produce a sequence gap. This should not be a problem though. correct?
      
      Test Plan: provided test.
      
      Reviewers: sdong
      
      Subscribers: andrewkr, leveldb, dhruba, hermanlee4
      
      Differential Revision: https://reviews.facebook.net/D57645
      a657ee9a
    • R
      [rocksdb] Two Phase Transaction · 8a66c85e
      Reid Horuff 提交于
      Summary:
      Two Phase Commit addition to RocksDB.
      
      See wiki: https://github.com/facebook/rocksdb/wiki/Two-Phase-Commit-Implementation
      Quip: https://fb.quip.com/pxZrAyrx53r3
      
      Depends on:
      WriteBatch modification: https://reviews.facebook.net/D54093
      Memtable Log Referencing and Prepared Batch Recovery: https://reviews.facebook.net/D56919
      
      Test Plan:
      - SimpleTwoPhaseTransactionTest
      - PersistentTwoPhaseTransactionTest.
      - TwoPhaseRollbackTest
      - TwoPhaseMultiThreadTest
      - TwoPhaseLogRollingTest
      - TwoPhaseEmptyWriteTest
      - TwoPhaseExpirationTest
      
      Reviewers: IslamAbdelRahman, sdong
      
      Reviewed By: sdong
      
      Subscribers: leveldb, hermanlee4, andrewkr, vasilep, dhruba, santoshb
      
      Differential Revision: https://reviews.facebook.net/D56925
      8a66c85e
    • R
      [rocksdb] Memtable Log Referencing and Prepared Batch Recovery · 1b8a2e8f
      Reid Horuff 提交于
      Summary:
      This diff is built on top of WriteBatch modification: https://reviews.facebook.net/D54093 and adds the required functionality to rocksdb core necessary for rocksdb to support 2PC.
      
      modfication of DBImpl::WriteImpl()
      - added two arguments *uint64_t log_used = nullptr, uint64_t log_ref = 0;
      - *log_used is an output argument which will return the log number which the incoming batch was inserted into, 0 if no WAL insert took place.
      -  log_ref is a supplied log_number which all memtables inserted into will reference after the batch insert takes place. This number will reside in 'FindMinPrepLogReferencedByMemTable()' until all Memtables insertinto have flushed.
      
      - Recovery/writepath is now aware of prepared batches and commit and rollback markers.
      
      Test Plan: There is currently no test on this diff. All testing of this functionality takes place in the Transaction layer/diff but I will add some testing.
      
      Reviewers: IslamAbdelRahman, sdong
      
      Subscribers: leveldb, santoshb, andrewkr, vasilep, dhruba, hermanlee4
      
      Differential Revision: https://reviews.facebook.net/D56919
      1b8a2e8f
    • R
      Modification of WriteBatch to support two phase commit · 0460e9dc
      Reid Horuff 提交于
      Summary: Adds three new WriteBatch data types: Prepare(xid), Commit(xid), Rollback(xid). Prepare(xid) should precede the (single) operation to which is applies. There can obviously be multiple Prepare(xid) markers. There should only be one Rollback(xid) or Commit(xid) marker yet not both. None of this logic is currently enforced and will most likely be implemented further up such as in the memtableinserter. All three markers are similar to PutLogData in that they are writebatch meta-data, ie stored but not counted. All three markers differ from PutLogData in that they will actually be written to disk. As for WriteBatchWithIndex, Prepare, Commit, Rollback are all implemented just as PutLogData and none are tested just as PutLogData.
      
      Test Plan: single unit test in write_batch_test.
      
      Reviewers: hermanlee4, sdong, anthony
      
      Subscribers: leveldb, dhruba, vasilep, andrewkr
      
      Differential Revision: https://reviews.facebook.net/D57867
      0460e9dc
    • A
      Follow symlinks in chroot directory · f548da33
      Andrew Kryczka 提交于
      Summary:
      On Mac OS X, the chroot directory we typically use ("/tmp") is actually
      a symlink for "/private/tmp". Since we dereference symlinks in user-defined
      paths, we must also dereference symlinks in chroot_dir_ such that we can perform
      string comparisons on those paths.
      
      Test Plan: ran env_test on Mac OS X and devserver
      
      Reviewers: sdong, IslamAbdelRahman
      
      Reviewed By: IslamAbdelRahman
      
      Subscribers: andrewkr, dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D57957
      f548da33
  4. 10 5月, 2016 7 次提交
    • I
      Fix lite build · d86f9b9c
      Islam AbdelRahman 提交于
      Summary: Fix lite build
      
      Test Plan: run under lite
      
      Subscribers: andrewkr, dhruba
      
      Differential Revision: https://reviews.facebook.net/D57945
      d86f9b9c
    • I
      Add bottommost_compression option · 4b317234
      Islam AbdelRahman 提交于
      Summary:
      Add a new option that can be used to set a specific compression algorithm for bottommost level.
      This option will only affect levels larger than base level.
      
      I have also updated CompactionJobInfo to include the compression algorithm used in compaction
      
      Test Plan:
      added new unittest
      existing unittests
      
      Reviewers: andrewkr, yhchiang, sdong
      
      Reviewed By: sdong
      
      Subscribers: lightmark, andrewkr, dhruba, yoshinorim
      
      Differential Revision: https://reviews.facebook.net/D57669
      4b317234
    • S
      Estimate pending compaction bytes more accurately · bfb6b1b8
      sdong 提交于
      Summary: Currently we estimate bytes needed for compaction by assuming fanout value to be level multiplier. It overestimates when size of a level exceeds the target by large. We estimate by the ratio of actual sizes in levels instead.
      
      Test Plan: Fix existing test cases and add a new one.
      
      Reviewers: IslamAbdelRahman, igor, yhchiang
      
      Reviewed By: yhchiang
      
      Subscribers: MarkCallaghan, leveldb, andrewkr, dhruba
      
      Differential Revision: https://reviews.facebook.net/D57789
      bfb6b1b8
    • A
      Properly destroy ChrootEnv in env_test · 258459ed
      Andrew Kryczka 提交于
      Summary: see title
      
      Test Plan:
        $ /mnt/gvfs/third-party2/valgrind/af85c56f424cd5edfc2c97588299b44ecdec96bb/3.10.0/gcc-4.9-glibc-2.20/e9936bf/bin/valgrind --error-exitcode=2 --leak-check=full ./env_test
      
      Reviewers: IslamAbdelRahman, sdong
      
      Reviewed By: sdong
      
      Subscribers: andrewkr, dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D57897
      258459ed
    • Y
      Initial script for the new regression test · fca5aa6f
      Yueh-Hsuan Chiang 提交于
      Summary:
      This diff includes an initial script running a set of benchmarks for
      regression test.  The script does the following things:
      
        checkout the specified rocksdb commit (or origin/master as default)
        make clean && DEBUG_LEVEL=0 make db_bench
        setup test directories
        run set of benchmarks and store results
      
      Currently, the script will run couple benchmarks, store all the benchmark
      output, extract micros per op and percentile information for each benchmark
      and store them in a single SUMMARY.csv file.  The SUMMARY.csv will make the
      follow-up regression detection easier.
      
      In addition, the current script only takes env arguments to set important
      attributes of db_bench.  Will follow-up with a patch that allows db_bench
      to construct options from an options file.
      
      Test Plan:
      NUM_KEYS=100 ./tools/regression_test.sh
      
        Sample SUMMARY.csv file:
      
                                           commit id,                      benchmark,  ms-per-op,        p50,        p75,        p99,      p99.9,     p99.99
            7e23ddf575890510e7d2fc7a79b31a1bbf317917,                        fillseq,      15.28,      54.66,      77.14,    5000.00,   17900.00,   18483.00
            7e23ddf575890510e7d2fc7a79b31a1bbf317917,                      overwrite,      13.54,      57.69,      86.39,    3000.00,   15600.00,   17013.00
            7e23ddf575890510e7d2fc7a79b31a1bbf317917,                     readrandom,       1.04,       0.80,       1.67,     293.33,     395.00,     504.00
            7e23ddf575890510e7d2fc7a79b31a1bbf317917,               readwhilewriting,       2.75,       1.01,       1.87,     200.00,     460.00,     485.00
            7e23ddf575890510e7d2fc7a79b31a1bbf317917,                   deleterandom,       3.64,      48.12,      70.09,     200.00,     336.67,     347.00
            7e23ddf575890510e7d2fc7a79b31a1bbf317917,                     seekrandom,      24.31,     391.87,     513.69,     872.73,     990.00,    1048.00
            7e23ddf575890510e7d2fc7a79b31a1bbf317917,         seekrandomwhilewriting,      14.02,     185.14,     294.15,     700.00,    1440.00,    1527.00
      
      Reviewers: sdong, IslamAbdelRahman, kradhakrishnan, yiwu, andrewkr, gunnarku
      
      Reviewed By: gunnarku
      
      Subscribers: gunnarku, MarkCallaghan, andrewkr, dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D57597
      fca5aa6f
    • I
      Add --index_block_restart_interval option in db_bench · e1951b6f
      Islam AbdelRahman 提交于
      Summary:
      Pass --index_block_restart_interval flag to block_based_options in db_bench tool.
      
      Test Plan: none
      
      Reviewers: sdong, kradhakrishnan
      
      Reviewed By: kradhakrishnan
      
      Subscribers: andrewkr, dhruba
      
      Differential Revision: https://reviews.facebook.net/D57699
      e1951b6f
    • Y
      Fix win build · 730f7e2e
      Yi Wu 提交于
      Summary: Fixing error with win build where we compare int64_t with size_t.
      
      Test Plan: make check
      
      Reviewers: andrewkr
      
      Reviewed By: andrewkr
      
      Subscribers: andrewkr, dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D57885
      730f7e2e
  5. 07 5月, 2016 9 次提交
  6. 06 5月, 2016 2 次提交
  7. 05 5月, 2016 3 次提交
    • M
      Add optimize_filters_for_hits option to db_bench · 9790b94c
      Mark Callaghan 提交于
      Summary:
      Add optimize_filters_for_hits option to db_bench
      
      Task ID: #
      
      Blame Rev:
      
      Test Plan:
      run db_bench
      
      Revert Plan:
      
      Database Impact:
      
      Memcache Impact:
      
      Other Notes:
      
      EImportant:
      
      - begin *PUBLIC* platform impact section -
      Bugzilla: #
      - end platform impact -
      
      Reviewers: sdong
      
      Reviewed By: sdong
      
      Subscribers: andrewkr, dhruba
      
      Differential Revision: https://reviews.facebook.net/D57621
      9790b94c
    • Y
      Fixing lite build · a4ea345b
      Yi Wu 提交于
      Summary: Fixing lite build broke in unit test. `FilesPerLevel()` depends on `DB::GetProperty()`, which lite build doesn't support.
      
      Test Plan: OPT=-DROCKSDB_LITE make check -j64
      
      Reviewers: sdong
      
      Reviewed By: sdong
      
      Subscribers: andrewkr, dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D57651
      a4ea345b
    • Y
      Enable configurable readahead for iterators · 24a24f01
      Yi Wu 提交于
      Summary:
      Add an option `iterator_readahead_size` to `ReadOptions` to enable
      configurable readahead for iterators similar to the corresponding
      option for compaction.
      
      Test Plan:
      ```
      make commit_prereq
      ```
      
      Reviewers: kumar.rangarajan, ott, igor, sdong
      
      Reviewed By: sdong
      
      Subscribers: yiwu, andrewkr, dhruba
      
      Differential Revision: https://reviews.facebook.net/D55419
      24a24f01
  8. 04 5月, 2016 1 次提交
    • I
      Fix Iterator::Prev memory pinning bug · ff4b3fb5
      Islam AbdelRahman 提交于
      Summary: We should not use IterKey::SetKey with copy = false except if we are pinning the iterator thru it's life time, otherwise we may release the temporarily pinned blocks and in this case the IterKey will be pointing to freed memory
      
      Test Plan: added a new test
      
      Reviewers: sdong, andrewkr
      
      Reviewed By: andrewkr
      
      Subscribers: andrewkr, dhruba
      
      Differential Revision: https://reviews.facebook.net/D57561
      ff4b3fb5
  9. 03 5月, 2016 4 次提交
    • P
      cba752d5
    • I
      Eliminate memcpy in Iterator::Prev() by pinning blocks for keys spanning multiple blocks · 6e801b0b
      Islam AbdelRahman 提交于
      Summary:
      This diff is stacked on top of this diff https://reviews.facebook.net/D56493
      The current Iterator::Prev() implementation need to copy every value since the underlying Iterator may move after reading the value.
      This can be optimized by making sure that the block containing the value is pinned until the Iterator move. which will improve the throughput by up to 1.5X
      
      master
      ```
      ==> 1000000_Keys_100Byte.txt <==
      readreverse  :       0.449 micros/op 2225887 ops/sec;  246.2 MB/s
      readreverse  :       0.433 micros/op 2311508 ops/sec;  255.7 MB/s
      readreverse  :       0.436 micros/op 2294335 ops/sec;  253.8 MB/s
      readreverse  :       0.471 micros/op 2121295 ops/sec;  234.7 MB/s
      readreverse  :       0.465 micros/op 2152227 ops/sec;  238.1 MB/s
      readreverse  :       0.454 micros/op 2203011 ops/sec;  243.7 MB/s
      readreverse  :       0.451 micros/op 2216095 ops/sec;  245.2 MB/s
      readreverse  :       0.462 micros/op 2162447 ops/sec;  239.2 MB/s
      readreverse  :       0.476 micros/op 2099151 ops/sec;  232.2 MB/s
      readreverse  :       0.472 micros/op 2120710 ops/sec;  234.6 MB/s
      
      avg : 242.34 MB/s
      
      ==> 1000000_Keys_1KB.txt <==
      readreverse  :       1.013 micros/op 986793 ops/sec;  978.7 MB/s
      readreverse  :       0.942 micros/op 1061136 ops/sec; 1052.5 MB/s
      readreverse  :       0.951 micros/op 1051901 ops/sec; 1043.3 MB/s
      readreverse  :       0.932 micros/op 1072894 ops/sec; 1064.1 MB/s
      readreverse  :       1.024 micros/op 976720 ops/sec;  968.7 MB/s
      readreverse  :       0.935 micros/op 1069169 ops/sec; 1060.4 MB/s
      readreverse  :       1.012 micros/op 988132 ops/sec;  980.1 MB/s
      readreverse  :       0.962 micros/op 1039579 ops/sec; 1031.1 MB/s
      readreverse  :       0.991 micros/op 1008924 ops/sec; 1000.7 MB/s
      readreverse  :       1.004 micros/op 996144 ops/sec;  988.0 MB/s
      
      avg : 1016.76 MB/s
      
      ==> 1000000_Keys_10KB.txt <==
      readreverse  :       4.167 micros/op 239952 ops/sec; 2346.9 MB/s
      readreverse  :       4.070 micros/op 245713 ops/sec; 2403.3 MB/s
      readreverse  :       4.572 micros/op 218733 ops/sec; 2139.4 MB/s
      readreverse  :       4.497 micros/op 222388 ops/sec; 2175.2 MB/s
      readreverse  :       4.203 micros/op 237920 ops/sec; 2327.1 MB/s
      readreverse  :       4.206 micros/op 237756 ops/sec; 2325.5 MB/s
      readreverse  :       4.181 micros/op 239149 ops/sec; 2339.1 MB/s
      readreverse  :       4.157 micros/op 240552 ops/sec; 2352.8 MB/s
      readreverse  :       4.187 micros/op 238848 ops/sec; 2336.1 MB/s
      readreverse  :       4.106 micros/op 243575 ops/sec; 2382.4 MB/s
      
      avg : 2312.78 MB/s
      
      ==> 100000_Keys_100KB.txt <==
      readreverse  :      41.281 micros/op 24224 ops/sec; 2366.0 MB/s
      readreverse  :      39.722 micros/op 25175 ops/sec; 2458.9 MB/s
      readreverse  :      40.319 micros/op 24802 ops/sec; 2422.5 MB/s
      readreverse  :      39.762 micros/op 25149 ops/sec; 2456.4 MB/s
      readreverse  :      40.916 micros/op 24440 ops/sec; 2387.1 MB/s
      readreverse  :      41.188 micros/op 24278 ops/sec; 2371.4 MB/s
      readreverse  :      40.061 micros/op 24962 ops/sec; 2438.1 MB/s
      readreverse  :      40.221 micros/op 24862 ops/sec; 2428.4 MB/s
      readreverse  :      40.084 micros/op 24947 ops/sec; 2436.7 MB/s
      readreverse  :      40.655 micros/op 24597 ops/sec; 2402.4 MB/s
      
      avg : 2416.79 MB/s
      
      ==> 10000_Keys_1MB.txt <==
      readreverse  :     298.038 micros/op 3355 ops/sec; 3355.3 MB/s
      readreverse  :     335.001 micros/op 2985 ops/sec; 2985.1 MB/s
      readreverse  :     286.956 micros/op 3484 ops/sec; 3484.9 MB/s
      readreverse  :     329.954 micros/op 3030 ops/sec; 3030.8 MB/s
      readreverse  :     306.428 micros/op 3263 ops/sec; 3263.5 MB/s
      readreverse  :     330.749 micros/op 3023 ops/sec; 3023.5 MB/s
      readreverse  :     328.903 micros/op 3040 ops/sec; 3040.5 MB/s
      readreverse  :     324.853 micros/op 3078 ops/sec; 3078.4 MB/s
      readreverse  :     320.488 micros/op 3120 ops/sec; 3120.3 MB/s
      readreverse  :     320.536 micros/op 3119 ops/sec; 3119.8 MB/s
      
      avg : 3150.21 MB/s
      ```
      
      After memcpy elimination
      ```
      
      ==> 1000000_Keys_100Byte.txt <==
      readreverse  :       0.395 micros/op 2529890 ops/sec;  279.9 MB/s
      readreverse  :       0.368 micros/op 2715922 ops/sec;  300.5 MB/s
      readreverse  :       0.384 micros/op 2603929 ops/sec;  288.1 MB/s
      readreverse  :       0.375 micros/op 2663286 ops/sec;  294.6 MB/s
      readreverse  :       0.357 micros/op 2802180 ops/sec;  310.0 MB/s
      readreverse  :       0.363 micros/op 2757684 ops/sec;  305.1 MB/s
      readreverse  :       0.372 micros/op 2689603 ops/sec;  297.5 MB/s
      readreverse  :       0.379 micros/op 2638599 ops/sec;  291.9 MB/s
      readreverse  :       0.375 micros/op 2663803 ops/sec;  294.7 MB/s
      readreverse  :       0.375 micros/op 2665579 ops/sec;  294.9 MB/s
      
      avg: 295.72 MB/s (1.22 X)
      
      ==> 1000000_Keys_1KB.txt <==
      readreverse  :       0.879 micros/op 1138112 ops/sec; 1128.8 MB/s
      readreverse  :       0.842 micros/op 1187998 ops/sec; 1178.3 MB/s
      readreverse  :       0.837 micros/op 1194915 ops/sec; 1185.1 MB/s
      readreverse  :       0.845 micros/op 1182983 ops/sec; 1173.3 MB/s
      readreverse  :       0.877 micros/op 1140308 ops/sec; 1131.0 MB/s
      readreverse  :       0.849 micros/op 1177581 ops/sec; 1168.0 MB/s
      readreverse  :       0.915 micros/op 1093284 ops/sec; 1084.3 MB/s
      readreverse  :       0.863 micros/op 1159418 ops/sec; 1149.9 MB/s
      readreverse  :       0.895 micros/op 1117670 ops/sec; 1108.5 MB/s
      readreverse  :       0.852 micros/op 1174116 ops/sec; 1164.5 MB/s
      
      avg: 1147.17 MB/s (1.12 X)
      
      ==> 1000000_Keys_10KB.txt <==
      readreverse  :       3.870 micros/op 258386 ops/sec; 2527.2 MB/s
      readreverse  :       3.568 micros/op 280296 ops/sec; 2741.5 MB/s
      readreverse  :       4.005 micros/op 249694 ops/sec; 2442.2 MB/s
      readreverse  :       3.550 micros/op 281719 ops/sec; 2755.5 MB/s
      readreverse  :       3.562 micros/op 280758 ops/sec; 2746.1 MB/s
      readreverse  :       3.507 micros/op 285125 ops/sec; 2788.8 MB/s
      readreverse  :       3.463 micros/op 288739 ops/sec; 2824.1 MB/s
      readreverse  :       3.428 micros/op 291734 ops/sec; 2853.4 MB/s
      readreverse  :       3.553 micros/op 281491 ops/sec; 2753.2 MB/s
      readreverse  :       3.535 micros/op 282885 ops/sec; 2766.9 MB/s
      
      avg : 2719.89 MB/s (1.17 X)
      
      ==> 100000_Keys_100KB.txt <==
      readreverse  :      22.815 micros/op 43830 ops/sec; 4281.0 MB/s
      readreverse  :      29.957 micros/op 33381 ops/sec; 3260.4 MB/s
      readreverse  :      25.334 micros/op 39473 ops/sec; 3855.4 MB/s
      readreverse  :      23.037 micros/op 43409 ops/sec; 4239.8 MB/s
      readreverse  :      27.810 micros/op 35958 ops/sec; 3512.1 MB/s
      readreverse  :      30.327 micros/op 32973 ops/sec; 3220.6 MB/s
      readreverse  :      29.704 micros/op 33665 ops/sec; 3288.2 MB/s
      readreverse  :      29.423 micros/op 33987 ops/sec; 3319.6 MB/s
      readreverse  :      23.334 micros/op 42856 ops/sec; 4185.9 MB/s
      readreverse  :      29.969 micros/op 33368 ops/sec; 3259.1 MB/s
      
      avg : 3642.21 MB/s (1.5 X)
      
      ==> 10000_Keys_1MB.txt <==
      readreverse  :     244.748 micros/op 4085 ops/sec; 4085.9 MB/s
      readreverse  :     230.208 micros/op 4343 ops/sec; 4344.0 MB/s
      readreverse  :     235.655 micros/op 4243 ops/sec; 4243.6 MB/s
      readreverse  :     235.730 micros/op 4242 ops/sec; 4242.2 MB/s
      readreverse  :     237.346 micros/op 4213 ops/sec; 4213.3 MB/s
      readreverse  :     227.306 micros/op 4399 ops/sec; 4399.4 MB/s
      readreverse  :     194.957 micros/op 5129 ops/sec; 5129.4 MB/s
      readreverse  :     238.359 micros/op 4195 ops/sec; 4195.4 MB/s
      readreverse  :     221.588 micros/op 4512 ops/sec; 4513.0 MB/s
      readreverse  :     235.911 micros/op 4238 ops/sec; 4239.0 MB/s
      
      avg : 4360.52 MB/s (1.38 X)
      ```
      
      Test Plan: COMPILE_WITH_ASAN=1 make check -j64
      
      Reviewers: andrewkr, yhchiang, sdong
      
      Reviewed By: sdong
      
      Subscribers: andrewkr, dhruba
      
      Differential Revision: https://reviews.facebook.net/D56511
      6e801b0b
    • Y
      Release RocksDB 4.8.0 · 1b166928
      Yi Wu 提交于
      Summary: Release RocksDB 4.8.0
      
      Test Plan: N/A
      
      Reviewers: sdong, IslamAbdelRahman
      
      Reviewed By: IslamAbdelRahman
      
      Subscribers: andrewkr, dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D57525
      1b166928
    • W
      Fix #1110, 32-bit build failure on Mac OSX (#1112) · b8cf9130
      Warren Falk 提交于
      Using explicit 64-bit type in conditional in platforms above 32-bits
      This appears to be necessary on Mac OSX as std::conditional does not appear to short circuit and evaluates the third template arg
      Making the third template arg be 64 bits explicitly works around this problem and will work on both 32 bit and 64+ bit platforms.
      b8cf9130