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
osd: bail out if transaction size overflows #10753
Conversation
Let's talk about this in standup tomorrow. |
will check if we have a guard for file journal because the transaction size could be greater than the size of file journal! |
changelog
|
|
||
// store new maps: queue for disk and put in the osdmap cache | ||
epoch_t start = MAX(superblock.newest_map + 1, first); | ||
for (epoch_t e = start; e <= last; e++) { | ||
if (txn_size > t.get_num_bytes()) { | ||
derr << __func__ << " transaction size overflowed" << dendl; | ||
assert(txn_size > t.get_num_bytes()); |
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.
@tchaikov I think this assert has no effect(always true)?
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.
right. will fix.
with a large MOSDMap message, the transaction size could be greater than UINT_MAX. so fail early with error messages. Fixes: http://tracker.ceph.com/issues/16982 Signed-off-by: Kefu Chai <kchai@redhat.com>
if a transaction is too large to fit in the FileJournal's ring buffer, we will wait. but if its size is larger than the max_size, it's likely due to a bug or an invalid setting. in that case, we'd better fail earlier. Fixes: http://tracker.ceph.com/issues/16982 Signed-off-by: Kefu Chai <kchai@redhat.com>
changelog
|
lgtm, adding needs-qa |
with a large MOSDMap message, the transaction size could be greater than
UINT_MAX. so fail early with error messages.
Fixes: http://tracker.ceph.com/issues/16982
Signed-off-by: Kefu Chai kchai@redhat.com