hammer: OSD crashed when reached pool's max_bytes quota
Check for full before changing the cached obc
ReplicatedPG::prepare_transaction(): check if the pool is full before
updating the cached ObjectContext to avoid the discrepancy between
the cached and the actual object size (and other metadata).
While at it improve the check itself: consider cluster full flag,
not just the pool full flag, also consider object count changes too,
not just bytes.
Based on commit a1eb380c3d5254f9f1fe34b4629e51d77fe010c1
Signed-off-by: Alexey Sheplyakov <firstname.lastname@example.org>
#11 Updated by Alexey Sheplyakov over 4 years ago
The commit introduces a regression
The commit exposes a bug in the test which assumes it's possible to write more data than the storage capacity is.
I believe that OSD should reject such writes to prevent further damage (ENOSPC handling in filesystems' code is not 100% fool proof), and it does so in Infernalis and Jewel.
and is reverted by http://tracker.ceph.com/issues/15019
I don't think reverting it is a good idea, the test case itself should be fixed instead.
Even if we want to pretend that it's possible to write 144 MB of data to a 100 MB drive
the check should be slightly modified, that is, https://github.com/ceph/ceph/blob/hammer/src/osd/ReplicatedPG.cc#L5693 should be removed,
instead of reintroducing the obc corruption. However I think checking for a full OSD is actually correct.