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