Ceph : Issueshttps://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2014-09-05T01:35:43ZCeph
Redmine rgw - Feature #9359 (Resolved): rgw: Export user stats in get-user-info Adminops APIhttps://tracker.ceph.com/issues/93592014-09-05T01:35:43ZXiangyu Lvraylv@yahoo-inc.com
<p>The user stats is useful information to view the space usage and total number of objects aggreagated at user level. It can be viewed with radosgw-admin user stats --uid=<uid> command. However, the current get-user-info Adminops API (<a class="external" href="http://ceph.com/docs/next/radosgw/adminops/#get-user-info">http://ceph.com/docs/next/radosgw/adminops/#get-user-info</a>) does not contain such information there. It can be added in a mimic way as get-user-info API (<a class="external" href="http://ceph.com/docs/next/radosgw/adminops/#get-bucket-info">http://ceph.com/docs/next/radosgw/adminops/#get-bucket-info</a>).</p>
<p>REQUEST PARAMETERS<br />- stats<br /> - Description: Return bucket statistics.<br /> - Type: Boolean<br /> - Example: True [False]<br /> - Required: No</p>
<p>RESPONSE ENTITIES<br />- stats<br /> - Description: Per user stats as accounted by quota subsystem.<br /> - Type: Container</p>
<p>Sample Reuquest<br />GET /{admin}/user?format=json&uid=foo_user&stats=true</p>
<p>Sample Response
{<br /> "user_id":"foo_user",<br /> "display_name":"foo_user",<br /> "email":"","suspended":0,<br /> "max_buckets":1000,<br /> "subusers":[],<br /> "keys":[],<br /> "swift_keys":[],<br /> "caps":[],<br /> "stats": {<br /> "total_entries": 2,<br /> "total_bytes": 308,<br /> "total_bytes_rounded": 8192,<br /> }<br />}</p> rgw - Bug #8583 (Resolved): rgw: admin ops create user API can not determine existing userhttps://tracker.ceph.com/issues/85832014-06-11T07:08:46ZXiangyu Lvraylv@yahoo-inc.com
<p>Version: Firefly 0.8.0</p>
<p>Reproduce Steps:<br />1) Failed to create a user only with uid<br />PUT /admin/user?format=json&uid=foo<br />400 Bad Request
{"Code":"InvalidArgument"}</p>
<p>2) Succeeded to create a user with uid and display-name<br />PUT /admin/user?format=json&uid=foo&display-name=foo<br />200 OK</p>
<p>3) Succeeded to create a user again with uid and display-name<br />PUT /admin/user?format=json&uid=foo&display-name=foo<br />200 OK</p>
<p>The change proposal here is to make create a user only with uid succeed and there after fail.</p> rgw - Feature #8562 (Resolved): rgw: Conditional PUT on ETaghttps://tracker.ceph.com/issues/85622014-06-08T21:13:17ZXiangyu Lvraylv@yahoo-inc.com
<p>The object versioning has not been implemented yet in RGW. But there are some use cases that different sources concurrently write to the same item. It introduces lost update issue without object versioning.</p>
<p>Anouther simpler approach for preventing lost updates is the Conditional PUT on ETag and retrying on client side. The behavior conforms to HTTP standard <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24" class="external">If-Match</a> and <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26" class="external">If-None-Match</a></p>
<ul>
<li>If-Match: <ETag>, If the entity tag matches the entity tag of the entity that would have been returned in the response to a similar GET request (without the If-Match header) on that resource.</li>
<li>If-Match: *, The PUT will succeed if the resource exists; otherwise, it will fail.</li>
<li>If-None-Match: <ETag>, If the entity tag does not match the entity tag of the entity that would have been returned in the response to a similar GET request (without the If-None-Match header) on that resource.</li>
<li>If-None-Match: *, The PUT will succeed if the resource does not exist; otherwise, it will fail.</li>
</ul> rgw - Bug #7543 (Resolved): rgw: off-by-one bug in rgw_trim_whitespace()https://tracker.ceph.com/issues/75432014-02-26T02:38:26ZXiangyu Lvraylv@yahoo-inc.com
<p>There is an off-by-one bug in rgw_trim_whitespace(). It results in trimming off all characters with input like " t".</p> Ceph - Bug #7172 (Resolved): osd: OSD failed to start with osd_leveldb_cache_size > 0https://tracker.ceph.com/issues/71722014-01-17T04:38:09ZXiangyu Lvraylv@yahoo-inc.com
<p>After applying osd_leveldb_cache_size = 52428800 on an OSD host, 2 ~ 3 OSDs on<br />the host failed to start due to the following crashing pattern:</p>
<pre><code>-2> 2014-01-13 04:37:03.537958 7fb52657a700 20 journal write_thread_entry<br />woke up<br /> -1> 2014-01-13 04:37:03.537978 7fb52657a700 10 journal write_thread_entry<br />finish<br /> 0> 2014-01-13 04:37:03.538914 7fb52853e700 -1 *<strong>* Caught signal<br />(Segmentation fault) *</strong><br /> in thread 7fb52853e700</code></pre>
<pre><code>ceph version 0.67.4-85-gc117914 (c117914b3d174aade9e6ceb9a0ca418dd6d73b60)<br /> 1: /usr/bin/ceph-osd() [0x80d2d9]<br /> 2: /lib64/libpthread.so.0() [0x3eba20f500]<br /> 3: (leveldb::InternalFilterPolicy::CreateFilter(leveldb::Slice const*, int,<br />std::string*) const+0x51) [0x3de3c22031]<br /> 4: (leveldb::FilterBlockBuilder::GenerateFilter()+0x13c) [0x3de3c35ccc]<br /> 5: (leveldb::FilterBlockBuilder::StartBlock(unsigned long)+0x30)<br />[0x3de3c35da0]<br /> 6: (leveldb::TableBuilder::Flush()+0xa2) [0x3de3c39292]<br /> 7: (leveldb::TableBuilder::Add(leveldb::Slice const&, leveldb::Slice<br />const&)+0x1cf) [0x3de3c3952f]<br /> 8:<br />(leveldb::DBImpl::DoCompactionWork(leveldb::DBImpl::CompactionState*)+0x5a8)<br />[0x3de3c1dd38]<br /> 9: (leveldb::DBImpl::BackgroundCompaction()+0x251) [0x3de3c1e531]<br /> 10: (leveldb::DBImpl::BackgroundCall()+0x90) [0x3de3c1ec50]<br /> 11: /usr/lib64/libleveldb.so.1() [0x3de3c3dc6f]<br /> 12: /lib64/libpthread.so.0() [0x3eba207851]<br /> 13: (clone()+0x6d) [0x3eb9ee890d]<br /> NOTE: a copy of the executable, or `objdump -rdS &lt;executable&gt;` is needed to<br />interpret this.</code></pre> rgw - Bug #7168 (Resolved): 404 Errors When save immediately follows a deletehttps://tracker.ceph.com/issues/71682014-01-16T05:14:59ZXiangyu Lvraylv@yahoo-inc.com
<p>If the delete operation clashed with the save, and the save returned an 404. Is there an option to make save successful anyway even though there are ongoing deletes?</p>
<p>The radosgw log:<br />2013-11-28 02:12:41.368090 7f118a643700 2 req 11275333:0.000072::HEAD /Flickr7454m/11093685123::initializing<br />2013-11-28 02:12:41.497465 7f118a643700 2 req 11275333:0.129447:s3:HEAD /Flickr7454m/11093685123:get_obj:http status=200<br />2013-11-28 02:12:41.499747 7f1242d6a700 1 ====== starting new request req=0x9c6fa0 ===== The delete op started<br />2013-11-28 02:12:41.499824 7f1242d6a700 2 req 11275346:0.000078::POST /Flickr7454m/::initializing<br />2013-11-28 02:12:41.501611 7f1242d6a700 2 req 11275346:0.001865:s3:POST /Flickr7454m/:multi_object_delete:reading permissions<br />2013-11-28 02:12:41.503435 7f1242d6a700 2 req 11275346:0.003689:s3:POST /Flickr7454m/:multi_object_delete:executing<br />2013-11-28 02:12:41.504509 7f116ee17700 1 ====== starting new request req=0xa25b20 ===== The PUT op started<br />2013-11-28 02:12:41.504577 7f116ee17700 2 req 11275348:0.000069::PUT /Flickr7454m/11093685123::initializing<br />2013-11-28 02:12:41.509087 7f116ee17700 2 req 11275348:0.004578:s3:PUT /Flickr7454m/11093685123:put_obj:reading permissions<br />2013-11-28 02:12:41.651838 7f1242d6a700 1 ====== req done req=0x9c6fa0 http_status=200 ====== The delete op succeeded <br />2013-11-28 02:12:41.734639 7f116ee17700 2 req 11275348:0.230131:s3:PUT /Flickr7454m/11093685123:put_obj:http status=404<br />2013-11-28 02:12:41.734730 7f116ee17700 1 ====== req done req=0xa25b20 http_status=404 ====== The PUT op failed</p> Ceph - Feature #7167 (Resolved): Add op_process_latency in perf countershttps://tracker.ceph.com/issues/71672014-01-16T04:59:08ZXiangyu Lvraylv@yahoo-inc.com
<p>We found that there is a need to get latency of op threads because op threads get slow during accessing LevelDB or getting/setting xattrs.</p> rgw - Bug #6672 (Resolved): normal PUT object requests got 405 sometimeshttps://tracker.ceph.com/issues/66722013-10-29T04:53:43ZXiangyu Lvraylv@yahoo-inc.com
<p>Under load testing, normal PUT object requests got 405 sometimes. The root cause is that there is a defect in hex_to_num() to decode url in multi-threading context.</p>