On 30 June 2015 at 16:03, Haomai Wang <[email protected]> wrote: > On Tue, Jun 30, 2015 at 4:55 AM, James (Fei) Liu-SSI > <[email protected]> wrote: >> Hi Haomai, >> Thanks for moving the idea forward. Regarding to the compression. >> However, if we do compression on the client level, it is not global. And >> the compression was only applied to the local client, am I right? I think >> there is pros and cons in two solutions and we can get into details more for >> each solution. > > Yes, I think a lot myself about compression with Ceph. At firstly, we > could easily use objectstore backend to implement compress like > filestore with zfs/btrfs and keyvaluestore with leveldb/rocksdb etc. > The advantages are we can enjoy it now. The cons are we may lose too > much for benefit of compression especially for performance.
If you were going to compress at the OSD I imagine the main performance concern would be about adding to write latency? That might be mitigated by only compressing the actual datastore and not the journal? I like the idea of having a compress option implemented in e.g. librbd and rgw, both of these cases involve scale-out clients and so concerns of performance overhead can be largely brushed aside (e.g., most OpenStack hypervisors seem to have plenty of free CPU). -- Cheers, ~Blairo -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
