@ -836,7 +836,7 @@ struct DBOptions {
// Allows OS to incrementally sync files to disk while they are being
// written, asynchronously, in the background. This operation can be used
// to smooth out write I/Os over time. Users shouldn't rely on it for
// persistency guarantee.
// persistence guarantee.
// Issue one request for every bytes_per_sync written. 0 turns it off.
//
// You may consider using rate_limiter to regulate write rate to device.
@ -1190,7 +1190,7 @@ struct DBOptions {
// writing a file, by tracing back to the writing host. These corruptions
// may not be caught by the checksum since they happen before checksumming.
// If left as default, the table writer will substitute it with the actual
// hostname when writing the SST file. If set to an empty sti rng, the
// hostname when writing the SST file. If set to an empty stri ng, the
// property will not be written to the SST file.
//
// Default: hostname
@ -1349,7 +1349,7 @@ struct ReadOptions {
// When true, by default use total_order_seek = true, and RocksDB can
// selectively enable prefix seek mode if won't generate a different result
// from total_order_seek, based on seek key, and iterator upper bound.
// Not suppp orted in ROCKSDB_LITE mode, in the way that even with value true
// Not supported in ROCKSDB_LITE mode, in the way that even with value true
// prefix mode is not used.
// Default: false
bool auto_prefix_mode ;
@ -1479,7 +1479,7 @@ struct WriteOptions {
bool no_slowdown ;
// If true, this write request is of lower priority if compaction is
// behind. In this case, no_slowdown = true, the request will be cancell ed
// behind. In this case, no_slowdown = true, the request will be canceled
// immediately with Status::Incomplete() returned. Otherwise, it will be
// slowed down. The slowdown value is determined by RocksDB to guarantee
// it introduces minimum impacts to high priority writes.
@ -1656,7 +1656,7 @@ struct IngestExternalFileOptions {
// will be ignored; 2) If DB enable the checksum function, we calculate the
// sst file checksum after the file is moved or copied and compare the
// checksum and checksum name. If checksum or checksum function name does
// not match, ingestion will be failed. If the verification is sucessful,
// not match, ingestion will be failed. If the verification is succ essful,
// checksum and checksum function name will be stored in Manifest.
// If this option is set to FALSE, 1) if DB does not enable checksum,
// the ingested checksum information will be ignored; 2) if DB enable the