2016-02-09 23:12:00 +00:00
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
2017-07-15 23:03:42 +00:00
|
|
|
// This source code is licensed under both the GPLv2 (found in the
|
|
|
|
// COPYING file in the root directory) and Apache 2.0 License
|
|
|
|
// (found in the LICENSE.Apache file in the root directory).
|
2015-08-05 03:45:27 +00:00
|
|
|
|
2016-12-22 01:35:00 +00:00
|
|
|
|
2019-05-30 03:44:08 +00:00
|
|
|
#include "file/delete_scheduler.h"
|
2015-08-19 22:02:17 +00:00
|
|
|
|
2020-06-05 16:41:03 +00:00
|
|
|
#include <cinttypes>
|
2015-08-05 03:45:27 +00:00
|
|
|
#include <thread>
|
|
|
|
#include <vector>
|
|
|
|
|
2019-05-30 03:44:08 +00:00
|
|
|
#include "file/sst_file_manager_impl.h"
|
2019-06-01 00:19:43 +00:00
|
|
|
#include "logging/logging.h"
|
2015-08-05 03:45:27 +00:00
|
|
|
#include "port/port.h"
|
|
|
|
#include "rocksdb/env.h"
|
2021-01-26 06:07:26 +00:00
|
|
|
#include "rocksdb/file_system.h"
|
|
|
|
#include "rocksdb/system_clock.h"
|
2019-05-31 00:39:43 +00:00
|
|
|
#include "test_util/sync_point.h"
|
2015-08-05 03:45:27 +00:00
|
|
|
#include "util/mutexlock.h"
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
namespace ROCKSDB_NAMESPACE {
|
2015-08-05 03:45:27 +00:00
|
|
|
|
2021-03-15 11:32:24 +00:00
|
|
|
DeleteScheduler::DeleteScheduler(SystemClock* clock, FileSystem* fs,
|
|
|
|
int64_t rate_bytes_per_sec, Logger* info_log,
|
2017-11-17 19:56:41 +00:00
|
|
|
SstFileManagerImpl* sst_file_manager,
|
2018-03-22 22:42:44 +00:00
|
|
|
double max_trash_db_ratio,
|
|
|
|
uint64_t bytes_max_delete_chunk)
|
2021-01-26 06:07:26 +00:00
|
|
|
: clock_(clock),
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
fs_(fs),
|
2017-06-12 23:51:37 +00:00
|
|
|
total_trash_size_(0),
|
2015-08-05 03:45:27 +00:00
|
|
|
rate_bytes_per_sec_(rate_bytes_per_sec),
|
|
|
|
pending_files_(0),
|
2018-03-22 22:42:44 +00:00
|
|
|
bytes_max_delete_chunk_(bytes_max_delete_chunk),
|
2015-08-05 03:45:27 +00:00
|
|
|
closing_(false),
|
|
|
|
cv_(&mu_),
|
2020-03-24 18:24:53 +00:00
|
|
|
bg_thread_(nullptr),
|
2016-01-29 02:35:01 +00:00
|
|
|
info_log_(info_log),
|
2017-11-17 19:56:41 +00:00
|
|
|
sst_file_manager_(sst_file_manager),
|
|
|
|
max_trash_db_ratio_(max_trash_db_ratio) {
|
2017-06-12 23:51:37 +00:00
|
|
|
assert(sst_file_manager != nullptr);
|
2017-11-17 19:56:41 +00:00
|
|
|
assert(max_trash_db_ratio >= 0);
|
2020-03-24 18:24:53 +00:00
|
|
|
MaybeCreateBackgroundThread();
|
2015-08-05 03:45:27 +00:00
|
|
|
}
|
|
|
|
|
2016-01-29 02:35:01 +00:00
|
|
|
DeleteScheduler::~DeleteScheduler() {
|
2015-08-05 03:45:27 +00:00
|
|
|
{
|
2016-10-18 05:22:48 +00:00
|
|
|
InstrumentedMutexLock l(&mu_);
|
2015-08-05 03:45:27 +00:00
|
|
|
closing_ = true;
|
|
|
|
cv_.SignalAll();
|
|
|
|
}
|
|
|
|
if (bg_thread_) {
|
|
|
|
bg_thread_->join();
|
|
|
|
}
|
2021-01-07 23:21:51 +00:00
|
|
|
for (const auto& it : bg_errors_) {
|
|
|
|
it.second.PermitUncheckedError();
|
|
|
|
}
|
2015-08-05 03:45:27 +00:00
|
|
|
}
|
|
|
|
|
2018-04-26 20:51:39 +00:00
|
|
|
Status DeleteScheduler::DeleteFile(const std::string& file_path,
|
2019-01-29 22:27:30 +00:00
|
|
|
const std::string& dir_to_sync,
|
|
|
|
const bool force_bg) {
|
2024-05-01 19:26:54 +00:00
|
|
|
uint64_t total_size = sst_file_manager_->GetTotalSize();
|
2022-10-25 01:34:52 +00:00
|
|
|
if (rate_bytes_per_sec_.load() <= 0 ||
|
|
|
|
(!force_bg &&
|
2024-05-01 19:26:54 +00:00
|
|
|
total_trash_size_.load() > total_size * max_trash_db_ratio_.load())) {
|
2017-06-12 23:51:37 +00:00
|
|
|
// Rate limiting is disabled or trash size makes up more than
|
|
|
|
// max_trash_db_ratio_ (default 25%) of the total DB size
|
2017-03-16 19:06:04 +00:00
|
|
|
TEST_SYNC_POINT("DeleteScheduler::DeleteFile");
|
2020-12-23 07:44:44 +00:00
|
|
|
Status s = fs_->DeleteFile(file_path, IOOptions(), nullptr);
|
2017-06-12 23:51:37 +00:00
|
|
|
if (s.ok()) {
|
2020-08-21 02:16:56 +00:00
|
|
|
s = sst_file_manager_->OnDeleteFile(file_path);
|
2020-06-05 16:41:03 +00:00
|
|
|
ROCKS_LOG_INFO(info_log_,
|
|
|
|
"Deleted file %s immediately, rate_bytes_per_sec %" PRIi64
|
2024-05-01 19:26:54 +00:00
|
|
|
", total_trash_size %" PRIu64 ", total_size %" PRIi64
|
|
|
|
", max_trash_db_ratio %lf",
|
2020-06-05 16:41:03 +00:00
|
|
|
file_path.c_str(), rate_bytes_per_sec_.load(),
|
2024-05-01 19:26:54 +00:00
|
|
|
total_trash_size_.load(), total_size,
|
|
|
|
max_trash_db_ratio_.load());
|
2020-06-26 22:33:51 +00:00
|
|
|
InstrumentedMutexLock l(&mu_);
|
2020-06-05 16:41:03 +00:00
|
|
|
RecordTick(stats_.get(), FILES_DELETED_IMMEDIATELY);
|
2016-01-29 02:35:01 +00:00
|
|
|
}
|
|
|
|
return s;
|
2015-08-05 03:45:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Move file to trash
|
2017-10-27 20:25:54 +00:00
|
|
|
std::string trash_file;
|
2020-12-23 07:44:44 +00:00
|
|
|
Status s = MarkAsTrash(file_path, &trash_file);
|
2020-06-05 16:41:03 +00:00
|
|
|
ROCKS_LOG_INFO(info_log_, "Mark file: %s as trash -- %s", trash_file.c_str(),
|
|
|
|
s.ToString().c_str());
|
2017-10-27 20:25:54 +00:00
|
|
|
|
2015-08-05 03:45:27 +00:00
|
|
|
if (!s.ok()) {
|
2019-12-18 04:07:21 +00:00
|
|
|
ROCKS_LOG_ERROR(info_log_, "Failed to mark %s as trash -- %s",
|
|
|
|
file_path.c_str(), s.ToString().c_str());
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
s = fs_->DeleteFile(file_path, IOOptions(), nullptr);
|
2017-06-12 23:51:37 +00:00
|
|
|
if (s.ok()) {
|
2020-08-21 02:16:56 +00:00
|
|
|
s = sst_file_manager_->OnDeleteFile(file_path);
|
2020-06-05 16:41:03 +00:00
|
|
|
ROCKS_LOG_INFO(info_log_, "Deleted file %s immediately",
|
|
|
|
trash_file.c_str());
|
2020-06-26 22:33:51 +00:00
|
|
|
InstrumentedMutexLock l(&mu_);
|
2020-06-05 16:41:03 +00:00
|
|
|
RecordTick(stats_.get(), FILES_DELETED_IMMEDIATELY);
|
2016-01-29 02:35:01 +00:00
|
|
|
}
|
|
|
|
return s;
|
2015-08-05 03:45:27 +00:00
|
|
|
}
|
|
|
|
|
2017-10-27 20:25:54 +00:00
|
|
|
// Update the total trash size
|
|
|
|
uint64_t trash_file_size = 0;
|
2021-01-06 22:14:01 +00:00
|
|
|
IOStatus io_s =
|
2020-12-23 07:44:44 +00:00
|
|
|
fs_->GetFileSize(trash_file, IOOptions(), &trash_file_size, nullptr);
|
2021-01-06 22:14:01 +00:00
|
|
|
if (io_s.ok()) {
|
|
|
|
total_trash_size_.fetch_add(trash_file_size);
|
|
|
|
}
|
|
|
|
//**TODO: What should we do if we failed to
|
|
|
|
// get the file size?
|
2017-10-27 20:25:54 +00:00
|
|
|
|
2015-08-05 03:45:27 +00:00
|
|
|
// Add file to delete queue
|
|
|
|
{
|
2016-10-18 05:22:48 +00:00
|
|
|
InstrumentedMutexLock l(&mu_);
|
2020-06-26 22:33:51 +00:00
|
|
|
RecordTick(stats_.get(), FILES_MARKED_TRASH);
|
2018-04-26 20:51:39 +00:00
|
|
|
queue_.emplace(trash_file, dir_to_sync);
|
2015-08-05 03:45:27 +00:00
|
|
|
pending_files_++;
|
|
|
|
if (pending_files_ == 1) {
|
|
|
|
cv_.SignalAll();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
2016-01-29 02:35:01 +00:00
|
|
|
std::map<std::string, Status> DeleteScheduler::GetBackgroundErrors() {
|
2016-10-18 05:22:48 +00:00
|
|
|
InstrumentedMutexLock l(&mu_);
|
2015-08-05 03:45:27 +00:00
|
|
|
return bg_errors_;
|
|
|
|
}
|
|
|
|
|
2017-10-27 20:25:54 +00:00
|
|
|
const std::string DeleteScheduler::kTrashExtension = ".trash";
|
|
|
|
bool DeleteScheduler::IsTrashFile(const std::string& file_path) {
|
|
|
|
return (file_path.size() >= kTrashExtension.size() &&
|
|
|
|
file_path.rfind(kTrashExtension) ==
|
|
|
|
file_path.size() - kTrashExtension.size());
|
|
|
|
}
|
|
|
|
|
|
|
|
Status DeleteScheduler::CleanupDirectory(Env* env, SstFileManagerImpl* sfm,
|
|
|
|
const std::string& path) {
|
2015-08-05 03:45:27 +00:00
|
|
|
Status s;
|
2017-10-27 20:25:54 +00:00
|
|
|
// Check if there are any files marked as trash in this path
|
|
|
|
std::vector<std::string> files_in_path;
|
2022-10-03 17:59:45 +00:00
|
|
|
const auto& fs = env->GetFileSystem();
|
|
|
|
IOOptions io_opts;
|
|
|
|
io_opts.do_not_recurse = true;
|
|
|
|
s = fs->GetChildren(path, io_opts, &files_in_path,
|
|
|
|
/*IODebugContext*=*/nullptr);
|
2017-10-27 20:25:54 +00:00
|
|
|
if (!s.ok()) {
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
for (const std::string& current_file : files_in_path) {
|
|
|
|
if (!DeleteScheduler::IsTrashFile(current_file)) {
|
|
|
|
// not a trash file, skip
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
Status file_delete;
|
|
|
|
std::string trash_file = path + "/" + current_file;
|
|
|
|
if (sfm) {
|
|
|
|
// We have an SstFileManager that will schedule the file delete
|
2020-08-21 02:16:56 +00:00
|
|
|
s = sfm->OnAddFile(trash_file);
|
2018-04-26 20:51:39 +00:00
|
|
|
file_delete = sfm->ScheduleFileDeletion(trash_file, path);
|
2017-10-27 20:25:54 +00:00
|
|
|
} else {
|
|
|
|
// Delete the file immediately
|
|
|
|
file_delete = env->DeleteFile(trash_file);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (s.ok() && !file_delete.ok()) {
|
|
|
|
s = file_delete;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
|
|
|
Status DeleteScheduler::MarkAsTrash(const std::string& file_path,
|
|
|
|
std::string* trash_file) {
|
|
|
|
// Sanity check of the path
|
2023-12-04 19:17:32 +00:00
|
|
|
size_t idx = file_path.rfind('/');
|
2015-08-05 03:45:27 +00:00
|
|
|
if (idx == std::string::npos || idx == file_path.size() - 1) {
|
|
|
|
return Status::InvalidArgument("file_path is corrupted");
|
|
|
|
}
|
|
|
|
|
2017-10-27 20:25:54 +00:00
|
|
|
if (DeleteScheduler::IsTrashFile(file_path)) {
|
|
|
|
// This is already a trash file
|
2017-12-13 02:15:15 +00:00
|
|
|
*trash_file = file_path;
|
2020-12-23 07:44:44 +00:00
|
|
|
return Status::OK();
|
2015-08-05 03:45:27 +00:00
|
|
|
}
|
|
|
|
|
2017-10-27 20:25:54 +00:00
|
|
|
*trash_file = file_path + kTrashExtension;
|
2015-08-05 03:45:27 +00:00
|
|
|
// TODO(tec) : Implement Env::RenameFileIfNotExist and remove
|
|
|
|
// file_move_mu mutex.
|
2017-10-27 20:25:54 +00:00
|
|
|
int cnt = 0;
|
2020-12-23 07:44:44 +00:00
|
|
|
Status s;
|
2016-10-18 05:22:48 +00:00
|
|
|
InstrumentedMutexLock l(&file_move_mu_);
|
2015-08-05 03:45:27 +00:00
|
|
|
while (true) {
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
s = fs_->FileExists(*trash_file, IOOptions(), nullptr);
|
2015-08-05 03:45:27 +00:00
|
|
|
if (s.IsNotFound()) {
|
|
|
|
// We found a path for our file in trash
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
s = fs_->RenameFile(file_path, *trash_file, IOOptions(), nullptr);
|
2015-08-05 03:45:27 +00:00
|
|
|
break;
|
|
|
|
} else if (s.ok()) {
|
|
|
|
// Name conflict, generate new random suffix
|
2017-10-27 20:25:54 +00:00
|
|
|
*trash_file = file_path + std::to_string(cnt) + kTrashExtension;
|
2015-08-05 03:45:27 +00:00
|
|
|
} else {
|
|
|
|
// Error during FileExists call, we cannot continue
|
|
|
|
break;
|
|
|
|
}
|
2017-10-27 20:25:54 +00:00
|
|
|
cnt++;
|
2015-08-05 03:45:27 +00:00
|
|
|
}
|
2017-06-12 23:51:37 +00:00
|
|
|
if (s.ok()) {
|
2021-01-06 22:14:01 +00:00
|
|
|
s = sst_file_manager_->OnMoveFile(file_path, *trash_file);
|
2016-01-29 02:35:01 +00:00
|
|
|
}
|
2015-08-05 03:45:27 +00:00
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
2016-01-29 02:35:01 +00:00
|
|
|
void DeleteScheduler::BackgroundEmptyTrash() {
|
|
|
|
TEST_SYNC_POINT("DeleteScheduler::BackgroundEmptyTrash");
|
2015-08-05 03:45:27 +00:00
|
|
|
|
|
|
|
while (true) {
|
2016-10-18 05:22:48 +00:00
|
|
|
InstrumentedMutexLock l(&mu_);
|
2015-08-05 03:45:27 +00:00
|
|
|
while (queue_.empty() && !closing_) {
|
|
|
|
cv_.Wait();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (closing_) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Delete all files in queue_
|
2021-01-26 06:07:26 +00:00
|
|
|
uint64_t start_time = clock_->NowMicros();
|
2015-08-05 03:45:27 +00:00
|
|
|
uint64_t total_deleted_bytes = 0;
|
2017-03-16 19:06:04 +00:00
|
|
|
int64_t current_delete_rate = rate_bytes_per_sec_.load();
|
2015-08-05 03:45:27 +00:00
|
|
|
while (!queue_.empty() && !closing_) {
|
2017-03-16 19:06:04 +00:00
|
|
|
if (current_delete_rate != rate_bytes_per_sec_.load()) {
|
|
|
|
// User changed the delete rate
|
|
|
|
current_delete_rate = rate_bytes_per_sec_.load();
|
2021-01-26 06:07:26 +00:00
|
|
|
start_time = clock_->NowMicros();
|
2017-03-16 19:06:04 +00:00
|
|
|
total_deleted_bytes = 0;
|
2020-06-05 16:41:03 +00:00
|
|
|
ROCKS_LOG_INFO(info_log_, "rate_bytes_per_sec is changed to %" PRIi64,
|
|
|
|
current_delete_rate);
|
2017-03-16 19:06:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Get new file to delete
|
2018-04-26 20:51:39 +00:00
|
|
|
const FileAndDir& fad = queue_.front();
|
|
|
|
std::string path_in_trash = fad.fname;
|
2015-08-05 03:45:27 +00:00
|
|
|
|
2020-02-28 22:10:51 +00:00
|
|
|
// We don't need to hold the lock while deleting the file
|
2015-08-05 03:45:27 +00:00
|
|
|
mu_.Unlock();
|
|
|
|
uint64_t deleted_bytes = 0;
|
2018-03-22 22:42:44 +00:00
|
|
|
bool is_complete = true;
|
2015-08-05 03:45:27 +00:00
|
|
|
// Delete file from trash and update total_penlty value
|
2018-04-26 20:51:39 +00:00
|
|
|
Status s =
|
|
|
|
DeleteTrashFile(path_in_trash, fad.dir, &deleted_bytes, &is_complete);
|
2015-08-05 03:45:27 +00:00
|
|
|
total_deleted_bytes += deleted_bytes;
|
|
|
|
mu_.Lock();
|
2018-03-22 22:42:44 +00:00
|
|
|
if (is_complete) {
|
2023-06-16 17:05:25 +00:00
|
|
|
RecordTick(stats_.get(), FILES_DELETED_FROM_TRASH_QUEUE);
|
2018-03-22 22:42:44 +00:00
|
|
|
queue_.pop();
|
|
|
|
}
|
2015-08-05 03:45:27 +00:00
|
|
|
|
|
|
|
if (!s.ok()) {
|
|
|
|
bg_errors_[path_in_trash] = s;
|
|
|
|
}
|
|
|
|
|
2020-06-05 16:41:03 +00:00
|
|
|
// Apply penalty if necessary
|
|
|
|
uint64_t total_penalty;
|
2017-03-16 19:06:04 +00:00
|
|
|
if (current_delete_rate > 0) {
|
|
|
|
// rate limiting is enabled
|
2020-06-05 16:41:03 +00:00
|
|
|
total_penalty =
|
2017-03-16 19:06:04 +00:00
|
|
|
((total_deleted_bytes * kMicrosInSecond) / current_delete_rate);
|
2020-06-05 16:41:03 +00:00
|
|
|
ROCKS_LOG_INFO(info_log_,
|
|
|
|
"Rate limiting is enabled with penalty %" PRIu64
|
2020-08-20 08:58:54 +00:00
|
|
|
" after deleting file %s",
|
2020-06-05 16:41:03 +00:00
|
|
|
total_penalty, path_in_trash.c_str());
|
|
|
|
while (!closing_ && !cv_.TimedWait(start_time + total_penalty)) {
|
|
|
|
}
|
2017-03-16 19:06:04 +00:00
|
|
|
} else {
|
|
|
|
// rate limiting is disabled
|
2020-06-05 16:41:03 +00:00
|
|
|
total_penalty = 0;
|
|
|
|
ROCKS_LOG_INFO(info_log_,
|
|
|
|
"Rate limiting is disabled after deleting file %s",
|
|
|
|
path_in_trash.c_str());
|
2017-03-16 19:06:04 +00:00
|
|
|
}
|
2016-01-29 02:35:01 +00:00
|
|
|
TEST_SYNC_POINT_CALLBACK("DeleteScheduler::BackgroundEmptyTrash:Wait",
|
2020-06-05 16:41:03 +00:00
|
|
|
&total_penalty);
|
2015-08-05 03:45:27 +00:00
|
|
|
|
2018-03-22 22:42:44 +00:00
|
|
|
if (is_complete) {
|
|
|
|
pending_files_--;
|
|
|
|
}
|
2015-08-05 03:45:27 +00:00
|
|
|
if (pending_files_ == 0) {
|
2015-08-19 22:02:17 +00:00
|
|
|
// Unblock WaitForEmptyTrash since there are no more files waiting
|
2015-08-05 03:45:27 +00:00
|
|
|
// to be deleted
|
|
|
|
cv_.SignalAll();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-01-29 02:35:01 +00:00
|
|
|
Status DeleteScheduler::DeleteTrashFile(const std::string& path_in_trash,
|
2018-04-26 20:51:39 +00:00
|
|
|
const std::string& dir_to_sync,
|
2018-03-22 22:42:44 +00:00
|
|
|
uint64_t* deleted_bytes,
|
|
|
|
bool* is_complete) {
|
2015-08-05 03:45:27 +00:00
|
|
|
uint64_t file_size;
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
Status s = fs_->GetFileSize(path_in_trash, IOOptions(), &file_size, nullptr);
|
2018-03-22 22:42:44 +00:00
|
|
|
*is_complete = true;
|
|
|
|
TEST_SYNC_POINT("DeleteScheduler::DeleteTrashFile:DeleteFile");
|
2015-08-05 03:45:27 +00:00
|
|
|
if (s.ok()) {
|
2018-03-22 22:42:44 +00:00
|
|
|
bool need_full_delete = true;
|
|
|
|
if (bytes_max_delete_chunk_ != 0 && file_size > bytes_max_delete_chunk_) {
|
2018-07-09 22:17:38 +00:00
|
|
|
uint64_t num_hard_links = 2;
|
|
|
|
// We don't have to worry aobut data race between linking a new
|
|
|
|
// file after the number of file link check and ftruncte because
|
|
|
|
// the file is now in trash and no hardlink is supposed to create
|
|
|
|
// to trash files by RocksDB.
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
Status my_status = fs_->NumFileLinks(path_in_trash, IOOptions(),
|
|
|
|
&num_hard_links, nullptr);
|
2018-03-22 22:42:44 +00:00
|
|
|
if (my_status.ok()) {
|
2018-07-09 22:17:38 +00:00
|
|
|
if (num_hard_links == 1) {
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
std::unique_ptr<FSWritableFile> wf;
|
2022-10-25 01:34:52 +00:00
|
|
|
my_status = fs_->ReopenWritableFile(path_in_trash, FileOptions(), &wf,
|
|
|
|
nullptr);
|
2018-07-09 22:17:38 +00:00
|
|
|
if (my_status.ok()) {
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
my_status = wf->Truncate(file_size - bytes_max_delete_chunk_,
|
|
|
|
IOOptions(), nullptr);
|
2018-07-09 22:17:38 +00:00
|
|
|
if (my_status.ok()) {
|
|
|
|
TEST_SYNC_POINT("DeleteScheduler::DeleteTrashFile:Fsync");
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
my_status = wf->Fsync(IOOptions(), nullptr);
|
2018-07-09 22:17:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (my_status.ok()) {
|
|
|
|
*deleted_bytes = bytes_max_delete_chunk_;
|
|
|
|
need_full_delete = false;
|
|
|
|
*is_complete = false;
|
|
|
|
} else {
|
|
|
|
ROCKS_LOG_WARN(info_log_,
|
|
|
|
"Failed to partially delete %s from trash -- %s",
|
|
|
|
path_in_trash.c_str(), my_status.ToString().c_str());
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
ROCKS_LOG_INFO(info_log_,
|
|
|
|
"Cannot delete %s slowly through ftruncate from trash "
|
|
|
|
"as it has other links",
|
|
|
|
path_in_trash.c_str());
|
2018-03-22 22:42:44 +00:00
|
|
|
}
|
2018-07-09 22:17:38 +00:00
|
|
|
} else if (!num_link_error_printed_) {
|
|
|
|
ROCKS_LOG_INFO(
|
|
|
|
info_log_,
|
|
|
|
"Cannot delete files slowly through ftruncate from trash "
|
|
|
|
"as Env::NumFileLinks() returns error: %s",
|
|
|
|
my_status.ToString().c_str());
|
|
|
|
num_link_error_printed_ = true;
|
2018-03-22 22:42:44 +00:00
|
|
|
}
|
|
|
|
}
|
2015-08-05 03:45:27 +00:00
|
|
|
|
2018-03-22 22:42:44 +00:00
|
|
|
if (need_full_delete) {
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
s = fs_->DeleteFile(path_in_trash, IOOptions(), nullptr);
|
2018-04-26 20:51:39 +00:00
|
|
|
if (!dir_to_sync.empty()) {
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
std::unique_ptr<FSDirectory> dir_obj;
|
2018-04-26 20:51:39 +00:00
|
|
|
if (s.ok()) {
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
s = fs_->NewDirectory(dir_to_sync, IOOptions(), &dir_obj, nullptr);
|
2018-04-26 20:51:39 +00:00
|
|
|
}
|
|
|
|
if (s.ok()) {
|
2021-11-03 19:20:19 +00:00
|
|
|
s = dir_obj->FsyncWithDirOptions(
|
|
|
|
IOOptions(), nullptr,
|
|
|
|
DirFsyncOptions(DirFsyncOptions::FsyncReason::kFileDeleted));
|
2018-04-26 20:51:39 +00:00
|
|
|
TEST_SYNC_POINT_CALLBACK(
|
|
|
|
"DeleteScheduler::DeleteTrashFile::AfterSyncDir",
|
Prefer static_cast in place of most reinterpret_cast (#12308)
Summary:
The following are risks associated with pointer-to-pointer reinterpret_cast:
* Can produce the "wrong result" (crash or memory corruption). IIRC, in theory this can happen for any up-cast or down-cast for a non-standard-layout type, though in practice would only happen for multiple inheritance cases (where the base class pointer might be "inside" the derived object). We don't use multiple inheritance a lot, but we do.
* Can mask useful compiler errors upon code change, including converting between unrelated pointer types that you are expecting to be related, and converting between pointer and scalar types unintentionally.
I can only think of some obscure cases where static_cast could be troublesome when it compiles as a replacement:
* Going through `void*` could plausibly cause unnecessary or broken pointer arithmetic. Suppose we have
`struct Derived: public Base1, public Base2`. If we have `Derived*` -> `void*` -> `Base2*` -> `Derived*` through reinterpret casts, this could plausibly work (though technical UB) assuming the `Base2*` is not dereferenced. Changing to static cast could introduce breaking pointer arithmetic.
* Unnecessary (but safe) pointer arithmetic could arise in a case like `Derived*` -> `Base2*` -> `Derived*` where before the Base2 pointer might not have been dereferenced. This could potentially affect performance.
With some light scripting, I tried replacing pointer-to-pointer reinterpret_casts with static_cast and kept the cases that still compile. Most occurrences of reinterpret_cast have successfully been changed (except for java/ and third-party/). 294 changed, 257 remain.
A couple of related interventions included here:
* Previously Cache::Handle was not actually derived from in the implementations and just used as a `void*` stand-in with reinterpret_cast. Now there is a relationship to allow static_cast. In theory, this could introduce pointer arithmetic (as described above) but is unlikely without multiple inheritance AND non-empty Cache::Handle.
* Remove some unnecessary casts to void* as this is allowed to be implicit (for better or worse).
Most of the remaining reinterpret_casts are for converting to/from raw bytes of objects. We could consider better idioms for these patterns in follow-up work.
I wish there were a way to implement a template variant of static_cast that would only compile if no pointer arithmetic is generated, but best I can tell, this is not possible. AFAIK the best you could do is a dynamic check that the void* conversion after the static cast is unchanged.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12308
Test Plan: existing tests, CI
Reviewed By: ltamasi
Differential Revision: D53204947
Pulled By: pdillinger
fbshipit-source-id: 9de23e618263b0d5b9820f4e15966876888a16e2
2024-02-07 18:44:11 +00:00
|
|
|
static_cast<void*>(const_cast<std::string*>(&dir_to_sync)));
|
2018-04-26 20:51:39 +00:00
|
|
|
}
|
|
|
|
}
|
2020-08-21 02:16:56 +00:00
|
|
|
if (s.ok()) {
|
|
|
|
*deleted_bytes = file_size;
|
|
|
|
s = sst_file_manager_->OnDeleteFile(path_in_trash);
|
|
|
|
}
|
2018-03-22 22:42:44 +00:00
|
|
|
}
|
|
|
|
}
|
2015-08-05 03:45:27 +00:00
|
|
|
if (!s.ok()) {
|
|
|
|
// Error while getting file size or while deleting
|
2017-03-16 02:22:52 +00:00
|
|
|
ROCKS_LOG_ERROR(info_log_, "Failed to delete %s from trash -- %s",
|
|
|
|
path_in_trash.c_str(), s.ToString().c_str());
|
2015-08-05 03:45:27 +00:00
|
|
|
*deleted_bytes = 0;
|
|
|
|
} else {
|
2018-03-22 22:42:44 +00:00
|
|
|
total_trash_size_.fetch_sub(*deleted_bytes);
|
2015-08-05 03:45:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
2016-01-29 02:35:01 +00:00
|
|
|
void DeleteScheduler::WaitForEmptyTrash() {
|
2016-10-18 05:22:48 +00:00
|
|
|
InstrumentedMutexLock l(&mu_);
|
2015-08-05 03:45:27 +00:00
|
|
|
while (pending_files_ > 0 && !closing_) {
|
|
|
|
cv_.Wait();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-24 18:24:53 +00:00
|
|
|
void DeleteScheduler::MaybeCreateBackgroundThread() {
|
2020-06-05 16:41:03 +00:00
|
|
|
if (bg_thread_ == nullptr && rate_bytes_per_sec_.load() > 0) {
|
2020-03-24 18:24:53 +00:00
|
|
|
bg_thread_.reset(
|
|
|
|
new port::Thread(&DeleteScheduler::BackgroundEmptyTrash, this));
|
2020-06-05 16:41:03 +00:00
|
|
|
ROCKS_LOG_INFO(info_log_,
|
|
|
|
"Created background thread for deletion scheduler with "
|
|
|
|
"rate_bytes_per_sec: %" PRIi64,
|
|
|
|
rate_bytes_per_sec_.load());
|
2020-03-24 18:24:53 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
} // namespace ROCKSDB_NAMESPACE
|
2016-12-22 01:35:00 +00:00
|
|
|
|