Enforce at least two portals being set/created if one set
xio_portals_thread = 1 by mistake
Return the correct last use portal and pass in only one portal
to accept
Signed-off-by: Vu Pham <vu@mellanox.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>
The log scraping is unfortunately O(n) in the size of the log. We can
also follow objects and then the prior_version pointers, but we don't have
a version->entry index at the moment.
Only index by reqid if reqid_is_index. Always index extra_reqids.
Notably, the PROMOTE op does not return true for reqid_is_indexed, but this
is where the promotion extra_reqids will appear.
Signed-off-by: Sage Weil <sage@redhat.com>
Fixes: #10194
Reuse the fcgx connection structure. It forces FCGX_Accept_r() freeing
up or reusing the connection if possible. This is needed for certain
fastcgi module (mod-proxy-fcgi) that sets the FCGI_KEEP_CONN, which
prevents the connection from being closed when calling FCGX_Finish_r().
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>