Skip to content
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.

Sign up for GitHub

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

Jump to bottom

storage: assert out on EIO in read #7633

Merged
merged 1 commit into from
Dec 12, 2022
Merged

storage: assert out on EIO in read #7633

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
15 changes: 12 additions & 3 deletions src/v/storage/log_reader.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -202,14 +202,23 @@ log_segment_batch_reader::read_some(model::timeout_clock::time_point timeout) {
_iterator = co_await initialize(timeout, cache_read.next_cached_batch);
}
auto ptr = _iterator.get();
co_return co_await ptr->consume().then(
[this](result<size_t> bytes_consumed) -> result<records_t> {
co_return co_await ptr->consume()
.then([this](result<size_t> bytes_consumed) -> result<records_t> {
if (!bytes_consumed) {
return bytes_consumed.error();
}
auto tmp = std::exchange(_state, {});
return result<records_t>(std::move(tmp.buffer));
});
})
.handle_exception_type(
[](const std::system_error& ec) -> ss::future<result<records_t>> {
if (ec.code().value() == EIO) {
vassert(false, "I/O error during read! Disk failure?");
Comment on lines +215 to +216
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

I'm curious if we'll hit a crash loop in automated deployments, but this still seems much better than the alternative. I wonder if longer term we'd want to peel back this limitation, e.g. assuming the entire disk isn't fully borked, stopping/moving just the replicas that hit a bad reads, while gracefully decommissioning the node.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Longer term, I suspect that for things like decode errors we'll want to treat them as non-crashing errors and report a "damaged" partition, but for EIOs we might always keep the termination behavior, as it's such a critical failure indicator.

} else {
return ss::make_exception_future<result<records_t>>(
std::current_exception());
Comment on lines +218 to +219
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we should pass ec here instead of std::current_exception. While future::handle_exception_type does invoke its continuation inside a catch block, that doesn't seem to be a guarantee that the API needs to maintain.

}
});
}

log_reader::log_reader(
Expand Down