Re: Adding compression support for bluestore.

[Igor Fedotov <ifedotov@mirantis.com>]

On 17.03.2016 21:53, Allen Samuels wrote:
>> I'd say "maybe". It's easy to say we should focus on read performance 
>> now, but as soon as we have "support for compression" everybody is 
>> going to want to turn it on on all of their clusters to spend less 
>> money on hard disks. That will definitely include RBD users, where 
>> write latency is very important. I'm hesitant to take an 
>> architectural direction that locks us in. With something layered over 
>> BlueStore I think we're forced to do it all in the initial phase; 
>> with the monolithic approach that integrates it into BlueStore's 
>> write path we have the option to do either one--perhaps based on the 
>> particular request or hints or whatever. 
> I completely agree with Sage. I think it's useful to separate mechanism from policy here. Specifically, I would push to have an onode/extent mechanism representation that supports a wide range of physical representation options (overlays in KV store, overlays in block store, overlapping extents, lazy space recovery, etc.) and allow the policy (i.e., RMW compression before ack, lazy space recovery later, etc...) evolve. It may turn out that the best policies aren't apparent right now or that they may vary based on device and resource characteristics and constraints. Over time there are likely to be many places in the code that become aware of the specifics of the mechanism (integrity checkers, compactors, inspectors, etc.) but could remain ignorant of the policy (i.e., adopt whatever poli
 cy was chosen).
This sounds good but I have some concerns about the complexity of the 
task. I'm afraid it's not doable without total (and very complex) 
bluestore refactoring.
Will try to address more or less in the next proposal though.

Thanks,
Igor