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 policy 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
--
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
