On Fri, 6 Jul 2018, Casey Bodley wrote:
> On 06/28/2018 12:15 PM, kefu chai wrote:
> > i am adding interface for seastar to ObjectStore. but the ObjectStore
> > works in a completely different way than an "ordinary" seastar app
> > does. we use following pattern when serving write requests to
> > ObjectStore:
> >
> > 1. prepare a transaction named txn.
> > 2. hook callbacks to the transaction using txn.register_on_{applied,commit}
> > 3. queue the transaction using store->queue_transaction(collection, txn)
> > 4. the registered callbacks will be called in the ObjectStore's
> > execution thread or separated finisher thread.
> >
> > does it make sense if we expose a method like
> >
> > seastar::future<> commit_transaction(collection, txn)
> >
> > which allows the caller to wait on the completion of commit, and to
> > expect an exception if the commit fails somehow?
> >
> > currently, both FileStore and BlueStore are driven by Finishers and
> > ThreadPools, in other words, they live in alien threads. we can always
> > hook a wrapper functor will submit a continuation upon completion of
> > commit or applied to reactor from where the original
> > {queue,submit}_transactions() was called.
> >
> > but in long term, Seastore[0] will use run-to-completion model
> > whenever possible. the new methods added to ObjectStore also helps us
> > to shape Seastore.
> >
> > thoughts?
> >
> > ---
> > [0] http://docs.ceph.com/docs/master/dev/seastore/
> >
>
> If we're still going to rely on the Finisher threads in the short term, I
> don't think we really gain anything from extending the ObjectStore interface
> now. If I understand correctly, this commit_transation() could just as easily
> be a free function that lives outside of ObjectStore entirely. I think it's a
> good idea to explore the shape of SeaStore's interface, but it's probably
> better to keep that interface separate and internal to the seastar-osd for
> now, and just have it wrap the existing ObjectStore as needed.
Let's not forget that we can fully implement a futures-based interface
right now using MemStore and test the full stack. It will be slightly
misleading because the memstore future will always be fulfilled
immediately, but we can probably even kludge it to artificially delay or
something for testing purposes.
This let's us get a better handle on how things will perform in the new
world without being blocked on SeaStore...
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
