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>
Don't update this when we apply the log to our in-memory hitset! We should
only update this when we persist something to disk.
Signed-off-by: Sage Weil <sage@inktank.com>
