Linger operations will follow the object to the cache pool when the pool
overlay process is set. If we evict the object, the object_info_t will
go away along with the watch state and confusing things will happen.
Prevent that from happening by returning EBUSY when you try to evict a
watched object.
Note that you *can* flush a watched object, and the dirty flag will be
cleared. But you still can't evict it.
Signed-off-by: Sage Weil <sage@inktank.com>
After we get the copy-from data and unblock the obc, we still need to take
the RWWRITE lock on the object for the duration of the repop while we
actually apply the change locally.
Signed-off-by: Sage Weil <sage@inktank.com>
In the process of fixing this for flush, we break promote, so we need to
adjust them both here. Basic strategy: do not set user_modify, but handle
the user_version explicitly in the callbacks.
For copy_from, we don't have a clean way to pass the result through to
finish_copyfrom in do_osd_ops; do so by putting it in user_at_version. (If
we were to call finish_copyfrom directly from the callback this might
be simpler, but let's not go there right now.)
For promote, it is a trivial fix.
Signed-off-by: Sage Weil <sage@inktank.com>
Implement a rados operation that will flush a dirty object in the cache
tier by writing it back to the base tier.
Signed-off-by: Sage Weil <sage@inktank.com>
If we initiate a COPY_FROM as part of a FLUSH operation, we will need to
set a flag so that the read-side of the copy and join the existing
in-progress operation without taknig additional locks.
Similarly, we need to pass flags from the client indicating whether we
should ignore overlay or cache logic while performing the copy. These are
used by the promote and flush logic.
Note that none of these flags are exposed through librados (at least not
at this time).
Signed-off-by: Sage Weil <sage@inktank.com>
Add ability to reset iterator to a specific hash position. For now, we
just truncate this to the current PG. In the future, this may be more
precise.
Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Farnum <greg@inktank.com>
If the flag is set, send the op to the pool specified and ignore the
overlay. Note that this obsoletes the global Objecter flag.
It also makes these EINVAL correctly:
rados -p base cache-flush
rados -p base cache-evict
Signed-off-by: Sage Weil <sage@inktank.com>
The second part of execute_ctx() is doing some somewhat generic work to
make the prepared updates in the ctx apply, updating the obc's cached
values. Factor it out.
Signed-off-by: Sage Weil <sage@inktank.com>
Flush puts us in an conundrum:
- the flush eventually writes, behaving like a write
- writes take the write lock at the start
- to flush, we send copy-from to the base pool, which does a copy-get on
our object
- the copy-get is a read, that blocks on the write.
This flag will allow an op to skip the initial locking step. It will need
to take it later, of course.
Signed-off-by: Sage Weil <sage@inktank.com>
Conflicts:
src/osd/ReplicatedPG.cc
We asserted that the client was not an OSD years ago when we separated out
the client and cluster networks. Now, we are about to allow an OSD to
trigger a copy_from on another pool (for cache flush) and the assert can
go away. We've long since verified that the messages are going out on
the correct interfaces.
Signed-off-by: Sage Weil <sage@inktank.com>
If an op starts with DELETE there is no need to promote the old content
from the base tier. Note that this only works if the FAILOK flag is
set. Otherwise, we need to know whether the object existed or not to
return either 0 or -ENOENT.
Signed-off-by: Sage Weil <sage@inktank.com>
Add a flag that will make the OSD bypass the cache overlay logic. This is
needed in order to handle operations like CACHE_EVICT and CACHE_FLUSH.
Signed-off-by: Sage Weil <sage@inktank.com>
