Hi Kefu,
I think Greg's comment the other day is right. You and Casey probably
know seastar better than anyone else working on Ceph at this point, so
I'd suggest just using your best judgment. I think for bluestore we
have many other areas that we'd need to work on for the
run-to-completion work to really matter. As long as it's not a major
regression for bluestore/filestore, I guess I'd focus more on what
you'll need to make a clean interface for seastore.
Mark
On 06/28/2018 11:15 AM, 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/
--
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
