On Wed, 1 Jun 2016, Haomai Wang wrote: > From my current view, prefix could be more flexible. For example, each > rgw bucket index could use one prefix to make each bucket index object > seek separated. For CF, it would be too heavry. It seems likeI the CF and prefix seek are solving different problems. A new column family means we can have different compaction parameters/policies and cache sizes/policies for different types of data (onode vs omap, say). The prefix seek thing just seems like a smart optimization for any non-Wholespace iterator... something we should just implement in the rocksdb KeyValueDB glue interface. I did a quick grep on the code and it looks like there is only one (one!) caller to prev() on an iterator: int DBObjectMap::DBObjectMapIteratorImpl::in_complete_region( const string &to_test, string *begin, string *end); in FileStore. We could make a special iterator creation parameter to allow bidirectional iteration, since every other caller doesn't need it, and use the prefix thing for forward-only? Or just drop prev() support completely from rocksdb (nobody should be using it with filestore on a production OSD since it's marked experimental) and be done with it... sage -- 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