Ceph : Issueshttps://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2017-12-10T19:16:36ZCeph
Redmine CephFS - Cleanup #22359 (New): mds: change MDSMap::in to a mds_rank_t which is the current size o...https://tracker.ceph.com/issues/223592017-12-10T19:16:36ZPatrick Donnellypdonnell@redhat.com
<p>Now that we no longer allow deactivating arbitrary ranks, it makes sense to change the `std::set<mds_rank_t> MDSMap::in` to a simple `mds_rank_t`. This is the current max rank.</p> RADOS - Feature #21760 (In Progress): add tools to stress RADOS omaphttps://tracker.ceph.com/issues/217602017-10-11T13:37:20ZDouglas Fuller
<p>Add the tools omap_create and omap_delete to stress the RADOS object map directly.</p> Linux kernel client - Fix #11418 (Fix Under Review): rbd: feature bits should be re-read during h...https://tracker.ceph.com/issues/114182015-04-16T23:34:24ZJosh Durgin
<p>The kernel client was originally assuming feature bits would not change, and just reading an image's features once during mapping. The exclusive lock and object map features can now be added by userspace dynamically.</p>
<p>The features should be refreshed during the usual header refresh path. It's debatable what should happen when these are added to a mapped image... The image should at least go read only, and perhaps return EIO as well.</p>
<p>If the features are removed, and only compatible features are left, krbd could start accepting requests again, but it may not be worth the complexity of avoiding an unmap/remap.</p> Linux kernel client - Fix #11234 (Fix Under Review): rbd does many requests to the header on star...https://tracker.ceph.com/issues/112342015-03-25T16:26:00ZJosh Durgin
<p>This can be collapsed into a few requests, like cls_client::[im]mutable_metadata() in userspace.</p>
<p>Multiple cls ops can be packed into one rados request.</p> Linux kernel client - Cleanup #11230 (New): get rid of struct rbd_mappinghttps://tracker.ceph.com/issues/112302015-03-25T16:15:27ZJosh Durgin
<p>put actual mapping values into struct rbd_image_header instead of keeping around both base image and actual mapping values with the possibility of confusing them</p> Linux kernel client - Bug #4689 (New): libceph: don't have alloc_msg methods limit lengthhttps://tracker.ceph.com/issues/46892013-04-08T18:51:27ZAlex Elderelder@ieee.org
<p>When an incoming message arrives, the messenger calls the<br />module it's destined for (osd client, mds client, mod client)<br />to request the message to receive the data into.</p>
<p>In the osd client the alloc_msg method calls get_reply()<br />to look up the request that will contain the reply message.<br />That function compares the incoming data length indicated<br />by the message header, and if it exceeds the space available<br />it will skip the message.</p>
<p>Now that messages support multiple data item this is not the<br />correct thing to do. It is based on the assumption that<br />there can only be one piece of data in the message.</p>
<p>Instead, the check (if it's done at all in this location)<br />needs to take into account the sizes of the data items<br />associated with osd ops that are receiving data.</p>
<p>Recently a change was put in that skips any message that<br />is too big to receive taking into account <strong>all</strong> data<br />items available to receive. That may be suffient, in<br />which case the check in the osd_client get_message()<br />function can just go away.</p>