New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
os/bluestore/BlueFS: several cleanups #17966
os/bluestore/BlueFS: several cleanups #17966
Conversation
2b5c5c4
to
503e5ff
Compare
503e5ff
to
863ec71
Compare
src/os/bluestore/BlueFS.cc
Outdated
@@ -1244,7 +1244,7 @@ void BlueFS::_compact_log_async(std::unique_lock<std::mutex>& l) | |||
<< std::dec << dendl; | |||
|
|||
// allocate | |||
int r = _allocate(BlueFS::BDEV_DB, new_log_jump_to, | |||
int r = _allocate(log_file->fnode.prefer_bdev, new_log_jump_to, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thinking here is that the async compaction isn't blocking, so it isn't latency sensitive.. and the wal device will generally only be big enough for the rocksdb .log files. Since this is only ever read on startup, I don't think there's much value in putting it on the wal device.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
other patches look good!
9e5b05b
to
ef0c60f
Compare
@liewegas Dropped that change! |
As block_all will suffice for the same purpose. Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
As Allocator will handle it automatically and efficiently! Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
As we might be allocating space from different devices (though the chance is rare). Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
retest this please |
retest this please |
No description provided.