sapling/eden/fs/store/RocksDbLocalStore.h

128 lines
3.9 KiB
C
Raw Normal View History

/*
* Copyright (c) Facebook, Inc. and its affiliates.
*
* This software may be used and distributed according to the terms of the
* GNU General Public License version 2.
*/
#pragma once
#include <folly/CppAttributes.h>
#include <folly/Synchronized.h>
#include <bitset>
#include "eden/fs/rocksdb/RocksHandles.h"
#include "eden/fs/store/LocalStore.h"
#include "eden/fs/utils/UnboundedQueueExecutor.h"
namespace facebook {
namespace eden {
Fix deadlock when restarting during RocksDbLocalStore::get() Summary: If TreeInode::startLoadingInode() is in progress, and EdenServer::startTakeoverShutdown() is called, edenfs can deadlock: 1. Thread A: A FUSE request calls TreeInode::readdir() -> TreeInode::prefetch() -> TreeInode::startLoadingInode() on the children TreeInode-s -> RocksDbLocalStore::getFuture(). 2. Thread B: A takeover request calls EdenServer::performTakeoverShutdown() -> InodeMap::shutdown(). 3. Thread C: RocksDbLocalStore::getFuture() (called in step 1) completes -> TreeInode::inodeLoadComplete(). (The inodeLoadComplete continuation was registered by TreeInode::registerInodeLoadComplete().) 4. Thread C: After TreeInode::inodeLoadComplete() returns, the TreeInode's InodePtr is destructed, dropping the reference count to 0. 5. Thread C: InodeMap::onInodeUnreferenced() -> InodeMap::shutdownComplete() -> EdenMount::shutdown() (called in step 2) completes -> EdenServer::performTakeoverShutdown(). 6. Thread C: EdenServer::performTakeoverShutdown() -> localStore_.reset() -> RocksDbLocalStore::~RocksDbLocalStore(). 7. Thread C: RocksDbLocalStore::~RocksDbLocalStore() signals the thread pool to exit and waits for the pool's threads to exit. Because thread C is one of the threads managed by RocksDbLocalStore's thread pool, the signal is never handled and RocksDbLocalStore::~RocksDbLocalStore() never finishes. Fix this deadlock by executing EdenServer::shutdown()'s callback (in EdenServer::performTakeoverShutdown()) on a different thread. Reviewed By: simpkins Differential Revision: D14337058 fbshipit-source-id: 1d63b4e7d8f5103a2dde31e329150bf763be3db7
2019-03-13 05:25:54 +03:00
class FaultInjector;
class StructuredLogger;
/** An implementation of LocalStore that uses RocksDB for the underlying
* storage.
*/
class RocksDbLocalStore : public LocalStore {
public:
Fix deadlock when restarting during RocksDbLocalStore::get() Summary: If TreeInode::startLoadingInode() is in progress, and EdenServer::startTakeoverShutdown() is called, edenfs can deadlock: 1. Thread A: A FUSE request calls TreeInode::readdir() -> TreeInode::prefetch() -> TreeInode::startLoadingInode() on the children TreeInode-s -> RocksDbLocalStore::getFuture(). 2. Thread B: A takeover request calls EdenServer::performTakeoverShutdown() -> InodeMap::shutdown(). 3. Thread C: RocksDbLocalStore::getFuture() (called in step 1) completes -> TreeInode::inodeLoadComplete(). (The inodeLoadComplete continuation was registered by TreeInode::registerInodeLoadComplete().) 4. Thread C: After TreeInode::inodeLoadComplete() returns, the TreeInode's InodePtr is destructed, dropping the reference count to 0. 5. Thread C: InodeMap::onInodeUnreferenced() -> InodeMap::shutdownComplete() -> EdenMount::shutdown() (called in step 2) completes -> EdenServer::performTakeoverShutdown(). 6. Thread C: EdenServer::performTakeoverShutdown() -> localStore_.reset() -> RocksDbLocalStore::~RocksDbLocalStore(). 7. Thread C: RocksDbLocalStore::~RocksDbLocalStore() signals the thread pool to exit and waits for the pool's threads to exit. Because thread C is one of the threads managed by RocksDbLocalStore's thread pool, the signal is never handled and RocksDbLocalStore::~RocksDbLocalStore() never finishes. Fix this deadlock by executing EdenServer::shutdown()'s callback (in EdenServer::performTakeoverShutdown()) on a different thread. Reviewed By: simpkins Differential Revision: D14337058 fbshipit-source-id: 1d63b4e7d8f5103a2dde31e329150bf763be3db7
2019-03-13 05:25:54 +03:00
/**
* The given FaultInjector must be valid during the lifetime of this
* RocksDbLocalStore object.
*/
explicit RocksDbLocalStore(
AbsolutePathPiece pathToRocksDb,
std::shared_ptr<StructuredLogger> structuredLogger,
FaultInjector* FOLLY_NONNULL faultInjector,
RocksDBOpenMode mode = RocksDBOpenMode::ReadWrite);
~RocksDbLocalStore();
void close() override;
void clearKeySpace(KeySpace keySpace) override;
void compactKeySpace(KeySpace keySpace) override;
StoreResult get(KeySpace keySpace, folly::ByteRange key) const override;
FOLLY_NODISCARD folly::Future<StoreResult> getFuture(
KeySpace keySpace,
folly::ByteRange key) const override;
FOLLY_NODISCARD folly::Future<std::vector<StoreResult>> getBatch(
KeySpace keySpace,
const std::vector<folly::ByteRange>& keys) const override;
bool hasKey(KeySpace keySpace, folly::ByteRange key) const override;
void put(KeySpace keySpace, folly::ByteRange key, folly::ByteRange value)
override;
std::unique_ptr<WriteBatch> beginWrite(size_t bufSize = 0) override;
// Call RocksDB's RepairDB() function on the DB at the specified location
static void repairDB(AbsolutePathPiece path);
// Get the approximate number of bytes stored on disk for the
// specified key space.
uint64_t getApproximateSize(KeySpace keySpace) const;
void periodicManagementTask(const EdenConfig& config) override;
private:
fix race conditions in RocksDbLocalStore access during shutdown Summary: This contains several fixes to LocalStore handling during shutdown. - Have EdenServer explicitly call localStore_->close() during shutdown. This ensures that the local store really gets close, just in case some other part of the code somehow still has an outstanding shared_ptr reference to it. - Add synchronization around internal access to the RocksDB object in RocksDbLocalStore. This ensures that calling `close()` is safe even if there happens to still be some outstanding I/O operations. In particular this helps ensure that if background GC operation is in progress that `close()` will wait until it completes before destroying the DB object. This also improves the code so that calling subsequent methods on a closed RocksDbLocalStore throws an exception, instead of simply crashing. I don't believe the additional synchronization in RocksDbLocalStore should have much impact on performance: the synchronization overhead should be very low compared to the cost of the RocksDB reads/writes. Ideally some of this synchronization logic should perhaps be moved into the base `LocalStore` class: all of the different `LocalStore` implementations should ideally ensure that `close()` is thread-safe and blocks until other pending I/O operations are complete. However, that requires a bigger refactoring. I may attempt that in a subsequent diff, but for now I mainly want to address this problem just for RocksDbLocalStore. Reviewed By: strager Differential Revision: D15948382 fbshipit-source-id: 96d633ac0879b3321f596224907fcfe72691b3f0
2019-06-25 04:26:34 +03:00
/**
* Get a pointer to the RocksHandles object in order to perform an I/O
* operation.
*
* Note that even though this acquires a read-lock, write operations to the
* DB may still be performed. The lock exists to prevent the DB from being
* closed while the I/O operation is in progress.
*/
folly::Synchronized<RocksHandles>::ConstRLockedPtr getHandles() const {
fix race conditions in RocksDbLocalStore access during shutdown Summary: This contains several fixes to LocalStore handling during shutdown. - Have EdenServer explicitly call localStore_->close() during shutdown. This ensures that the local store really gets close, just in case some other part of the code somehow still has an outstanding shared_ptr reference to it. - Add synchronization around internal access to the RocksDB object in RocksDbLocalStore. This ensures that calling `close()` is safe even if there happens to still be some outstanding I/O operations. In particular this helps ensure that if background GC operation is in progress that `close()` will wait until it completes before destroying the DB object. This also improves the code so that calling subsequent methods on a closed RocksDbLocalStore throws an exception, instead of simply crashing. I don't believe the additional synchronization in RocksDbLocalStore should have much impact on performance: the synchronization overhead should be very low compared to the cost of the RocksDB reads/writes. Ideally some of this synchronization logic should perhaps be moved into the base `LocalStore` class: all of the different `LocalStore` implementations should ideally ensure that `close()` is thread-safe and blocks until other pending I/O operations are complete. However, that requires a bigger refactoring. I may attempt that in a subsequent diff, but for now I mainly want to address this problem just for RocksDbLocalStore. Reviewed By: strager Differential Revision: D15948382 fbshipit-source-id: 96d633ac0879b3321f596224907fcfe72691b3f0
2019-06-25 04:26:34 +03:00
auto handles = dbHandles_.rlock();
if (!handles->db) {
throwStoreClosedError();
}
return handles;
}
[[noreturn]] void throwStoreClosedError() const;
std::shared_ptr<RocksDbLocalStore> getSharedFromThis() {
return std::static_pointer_cast<RocksDbLocalStore>(shared_from_this());
}
std::shared_ptr<const RocksDbLocalStore> getSharedFromThis() const {
return std::static_pointer_cast<const RocksDbLocalStore>(
shared_from_this());
}
struct AutoGCState {
bool inProgress_{false};
std::chrono::steady_clock::time_point startTime_;
};
struct SizeSummary {
/**
* Total size of ephemeral columns.
*/
uint64_t ephemeral = 0;
/**
* Total size of all persistent columns.
*/
uint64_t persistent = 0;
/**
* Which keyspace indices exceed their configured size limit and should be
* cleared.
*/
std::bitset<KeySpace::kTotalCount> excessiveKeySpaces;
};
/**
* Publish fb303 counters.
* Returns the approximate sizes of all column families.
*/
SizeSummary computeStats(bool publish, const EdenConfig* config);
void triggerAutoGC(SizeSummary before);
void autoGCFinished(bool successful, uint64_t ephemeralSizeBefore);
std::shared_ptr<StructuredLogger> structuredLogger_;
const std::string statsPrefix_{"local_store."};
Fix deadlock when restarting during RocksDbLocalStore::get() Summary: If TreeInode::startLoadingInode() is in progress, and EdenServer::startTakeoverShutdown() is called, edenfs can deadlock: 1. Thread A: A FUSE request calls TreeInode::readdir() -> TreeInode::prefetch() -> TreeInode::startLoadingInode() on the children TreeInode-s -> RocksDbLocalStore::getFuture(). 2. Thread B: A takeover request calls EdenServer::performTakeoverShutdown() -> InodeMap::shutdown(). 3. Thread C: RocksDbLocalStore::getFuture() (called in step 1) completes -> TreeInode::inodeLoadComplete(). (The inodeLoadComplete continuation was registered by TreeInode::registerInodeLoadComplete().) 4. Thread C: After TreeInode::inodeLoadComplete() returns, the TreeInode's InodePtr is destructed, dropping the reference count to 0. 5. Thread C: InodeMap::onInodeUnreferenced() -> InodeMap::shutdownComplete() -> EdenMount::shutdown() (called in step 2) completes -> EdenServer::performTakeoverShutdown(). 6. Thread C: EdenServer::performTakeoverShutdown() -> localStore_.reset() -> RocksDbLocalStore::~RocksDbLocalStore(). 7. Thread C: RocksDbLocalStore::~RocksDbLocalStore() signals the thread pool to exit and waits for the pool's threads to exit. Because thread C is one of the threads managed by RocksDbLocalStore's thread pool, the signal is never handled and RocksDbLocalStore::~RocksDbLocalStore() never finishes. Fix this deadlock by executing EdenServer::shutdown()'s callback (in EdenServer::performTakeoverShutdown()) on a different thread. Reviewed By: simpkins Differential Revision: D14337058 fbshipit-source-id: 1d63b4e7d8f5103a2dde31e329150bf763be3db7
2019-03-13 05:25:54 +03:00
FaultInjector& faultInjector_;
mutable UnboundedQueueExecutor ioPool_;
folly::Synchronized<AutoGCState> autoGCState_;
fix race conditions in RocksDbLocalStore access during shutdown Summary: This contains several fixes to LocalStore handling during shutdown. - Have EdenServer explicitly call localStore_->close() during shutdown. This ensures that the local store really gets close, just in case some other part of the code somehow still has an outstanding shared_ptr reference to it. - Add synchronization around internal access to the RocksDB object in RocksDbLocalStore. This ensures that calling `close()` is safe even if there happens to still be some outstanding I/O operations. In particular this helps ensure that if background GC operation is in progress that `close()` will wait until it completes before destroying the DB object. This also improves the code so that calling subsequent methods on a closed RocksDbLocalStore throws an exception, instead of simply crashing. I don't believe the additional synchronization in RocksDbLocalStore should have much impact on performance: the synchronization overhead should be very low compared to the cost of the RocksDB reads/writes. Ideally some of this synchronization logic should perhaps be moved into the base `LocalStore` class: all of the different `LocalStore` implementations should ideally ensure that `close()` is thread-safe and blocks until other pending I/O operations are complete. However, that requires a bigger refactoring. I may attempt that in a subsequent diff, but for now I mainly want to address this problem just for RocksDbLocalStore. Reviewed By: strager Differential Revision: D15948382 fbshipit-source-id: 96d633ac0879b3321f596224907fcfe72691b3f0
2019-06-25 04:26:34 +03:00
folly::Synchronized<RocksHandles> dbHandles_;
};
} // namespace eden
} // namespace facebook