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/
--
Regards
Kefu Chai
--
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
