Bug #24339
openFULL_FORCE ops are dropped if fail-safe full check fails, but not resent in scan_requests()
0%
Description
FULL_FORCE ops are dropped if fail-safe full check fails in do_op(). scan_requests() uses op->respects_full() which returns false for FULL_FORCE ops. This means that stuck FULL_FORCE ops may not get resent.
FULL_TRY ops aren't resent for the same reason, but they are never dropped -- either -ENOSPC or -EDQUOT is returned to the client.
Updated by Josh Durgin almost 6 years ago
- Project changed from Ceph to RADOS
- Category set to Correctness/Safety
- Priority changed from Normal to High
Updated by Sage Weil almost 6 years ago
- Status changed from New to 12
This is somewhat by design (or lack thereof)... the fail-safe check is there to prevent us from writing when we are really close to full. We aren't supposed to get to this point.
What is the scenario where you're seeing this happen?
Updated by Ilya Dryomov almost 6 years ago
Josh and I noticed this by code inspection. I'm nailing down out of space handling nits in the kernel client and wanted to confirm that both FULL_TRY and FULL_FORCE are guaranteed to return an error -- was making sure that neither needed resending.
Would it make sense to return -ENOSPC instead of just dropping a FULL_FORCE write, for consistency with FULL_TRY in the client code if nothing else?
Updated by Greg Farnum over 4 years ago
Eek what did you end up doing, Ilya? Anything happen here?
Updated by Ilya Dryomov over 4 years ago
Not to my knowledge, but I haven't checked in a while.