Import, export, and benchmark operations now use the librados
IO hints to indicate the read/write pattern and whether caching
is required.
Fixes: #10462
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Reviewed-by: Josh Durgin <jdurgin@redhat.com>
osd: index PGLog with optional extra_reqids in each log entry
Reviewed-by: Samuel Just <sjust@redhat.com>
Reviewed-by: Wang, Zhiqiang <zhiqiang.wang@intel.com>
Fixes: #10698
This fixes issue introduced in 8b3dfc9472,
where if user does not exist, we try keystone authentication. However,
if keystone is not configured we justt fall through without failing.
This would have failed later on due to bucket permissions, unless bucket
had a public write permissions.
Reported-by: Valery Tschopp <valery.tschopp@switch.ch>
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
Currently POST request on container returns 202 if success. But in Swift
the code is 204. Let's use 204 to keep align with the Swift API.
Fixes#10667
Signed-off-by: Yuan Zhou <yuan.zhou@intel.com>
For read/write op with LIBRADOS_OP_FLAG_FADVISE_DONTNEED,
the hit bh set this as true and later move into the tail of LRU in
order to remove in case in short future no ony access.
Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
1. bufferlist.c_str() will return a string which is longer than its real length.
This could cause an error result from do_xattr_cmp_u64. So use
std::string to receive the xattr
2. s/atoll/strtoull
Signed-off-by: Dongmao Zhang <deanraccoon@gmail.com>
crush: new straw2 bucket
Reviewed-by: Joao Eduardo Luis <joao@redhat.com>
Reviewed-by: Samuel Just <sjust@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>
As far as I can tell, the posix_fadvise() distinction between WONTNEED and
NOREUSE is subtle: one says I won't access the data, and the other says
I will access it one more time and then not access it. That is, the
distinction is about time. This thread seems to confirm this
interpretation:
https://lkml.org/lkml/2011/6/27/44
Since we are attaching hints to the IO operations themselves, this
distinction doesn't make much sense for us. (Backends should be careful
about which hint they use; or rather, they should use WONTNEED *after*
doing the IO since NOREUSE is presenting a no-op in Linux.)
However, we want to make a totally different distinction:
WONTNEED - nobody will access this -> drop it from the cache
NOCACHE - *i* won't access this again -> don't let me affect your caching
decisions or the working set you're maintaining for other
clients.
The NOCACHE name is made-up and distinct from NOREUSE only so that it is
different from POSIX and doesn't introduce confusion for people familiar
with the POSIX meaning. Perhaps a more accurate name would be IWONTNEED
but that is only one character apart and too error-prone IMO.
Signed-off-by: Sage Weil <sage@redhat.com>
Sometime after 1.55, boost introduced a forward declaration of
operator<< in optional.hpp. In 1.55 and earlier, when << was used
without the _io having been included, what got dumped was an implicit
bool conversion.
http://tracker.ceph.com/issues/10688 Refs: #10688
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
This fixes idempotency for operations across caching changes (promote,
flush and cache mode changes).
Fixes: #8935
Signed-off-by: Sage Weil <sage@redhat.com>
