On Wed, Sep 23, 2015 at 6:15 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > On Wed, 23 Sep 2015, Igor Fedotov wrote: >> Hi Sage, >> thanks a lot for your feedback. >> >> Regarding issues with offset mapping and stripe size exposure. >> What's about the idea to apply compression in two-tier (cache+backing storage) >> model only ? > > I'm not sure we win anything by making it a two-tier only thing... simply > making it a feature of the EC pool means we can also address EC pool users > like radosgw. > >> I doubt single-tier one is widely used for EC pools since there is no random >> write support in such mode. Thus this might be an acceptable limitation. >> At the same time it seems that appends caused by cached object flush have >> fixed block size (8Mb by default). And object is totally rewritten on the next >> flush if any. This makes offset mapping less tricky. >> Decompression should be applied in any model though as cache tier shutdown and >> subsequent compressed data access is possibly a valid use case. > > Yeah, we need to handle random reads either way, so I think the offset > mapping is going to be needed anyway. The idea of making the primary responsible for object compression really concerns me. It means for instance that a single random access will likely require access to multiple objects, and breaks many of the optimizations we have right now or in the pipeline (for instance: direct client access). And apparently only the EC pool will support compression, which is frustrating for all the replicated pool users out there... Is there some reason we don't just want to apply encryption across an OSD store? Perhaps doing it on the filesystem level is the wrong way (for reasons named above) but there are other mechanisms like inline block device compression that I think are supposed to work pretty well. The only thing that doesn't get us that I can see mentioned here is the over-the-wire compression — and Haomai already has patches for that, which should be a lot easier to validate and will work at all levels of the stack! -Greg -- 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
