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
