Bug #24339
open
FULL_FORCE ops are dropped if fail-safe full check fails, but not resent in scan_requests()
Added by Ilya Dryomov almost 6 years ago.
Updated almost 4 years ago.
Category:
Correctness/Safety
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.
- Project changed from Ceph to RADOS
- Category set to Correctness/Safety
- Priority changed from Normal to High
- 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?
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?
Eek what did you end up doing, Ilya? Anything happen here?
Not to my knowledge, but I haven't checked in a while.
- Status changed from 12 to New
- Priority changed from High to Normal
Also available in: Atom
PDF