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>
For the normal write path, prepare_transaction() handles this for us. In
this case, we need to do it explicitly.
Signed-off-by: Sage Weil <sage@inktank.com>
Most of the time we handle whiteouts by returning ENOENT before we even
get this far. However, for a mixed read/write transaction (e.g., a guard)
or certain ops (like create exclusive) we need to deal with the
exists == true and whiteout flag set case explicitly.
Signed-off-by: Sage Weil <sage@inktank.com>
If we get an error back, reply to the client directly and remove
the op which triggered promotion from our blocked op queue.
Signed-off-by: Greg Farnum <greg@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
This is not yet at all complete -- among other things, it will
retry forever on any object which doesn't exist in the underlying
pool. But it demonstrates the approach reasonably clearly.
Signed-off-by: Greg Farnum <greg@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>y
The return value is meaningless; nothing in this function can fail.
Signed-off-by: Greg Farnum <greg@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
The tuple was already unwieldy with 4 members; I didn't want to add
more. Instead, create a new CopyResults struct which contains all the
object info and completion data, and pass the retval and a CopyResults*
in the CopyCallbackResults tuple.
Signed-off-by: Greg Farnum <greg@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>