On Mon, Feb 1, 2016 at 9:08 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > On Mon, 1 Feb 2016, Yan, Zheng wrote: >> On Sat, Jan 30, 2016 at 12:09 AM, Sage Weil <sweil@xxxxxxxxxx> wrote: >> > Hi Zheng, >> > >> > We have one feature already merged to ceph.git, CRUSH_TUNABLES5, that's a >> > pretty trivial change to crush/mapper.c that we can add to the kernel. >> > >> > But there are two more coming: >> > >> > OSDOPREPLY_ENCODING makes a small change to the OSDOpReply encoding for >> > performance reasons. Here is the PR >> > >> > https://github.com/ceph/ceph/pull/7386 >> > >> > The other is the file layout changes, which are much more invovled: >> > >> > https://github.com/ceph/ceph/pull/7098 >> >> Can we avoid changing how file layout is encoded in MClientCaps and >> MClientReply? Instead, we encode the namespace information at the end >> of MClientCaps/MClientReply message. (like how we added inline data >> related fields to these message). > > Hmm.. yeah, we do that, at least for MClientCaps. It just means that if > we ever add more fields to that struct we need to maintain the message > encoding in parallel by hand, but that shouldn't be too bad. > > The MClientReply one is a bit trickier because there can be N instances of > InodeStat (or whatever) in there... on that one I'd lean toward switching > the encoding. What do you think? > We can use conection's features to decide how many memory each InodeStat uses. It's how inline data was added to InodeStat Regards Yan, Zheng -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
