Consider:
1- primary rx client delete
proxy delete to base pool
2- primary initiate promote (list-snaps, copy-from)
3- primary rx delete reply
4- primary tx client reply
5- socket failure drops client reply
6- primary rx promote completion (enoent), writes a whiteout
7- client resents delete
8- primary replies with ENOENT
i.e., the problem seems to be that delete is not idempotent and we can't
tell that the same client op is what triggered the delete.
We could special case delete since that is where this is noticeable, but I
think the bigger problem is that the op history that is used for dup op
detection is not preserved across the cache and base tier. That is, this
is another variation on this ticket:
http://tracker.ceph.com/issues/8935
I have this sinking feeling we need to properly address that problem
before we can do the write proxying...
sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
