FWIW, On Mon, 5 Nov 2018, kefu chai wrote: > hi, > > i am trying to note down the discussion on crimson we have in this morning: > > 1. osdmap cache: there are two approaches, > * C/S mode: shard#0 will act as the server. we could follow the model > of config proxy. say, let shard#0 be the mini server, and when a > certain shard, shard#n for instance, gets a new osdmap, it will inform > shard#0, by submitting following message to shard#0: > future<foreign_ptr<osdmap_ref>> add(foreign_ptr<osdmap_ref>&& map); > and here are two cases here, > 1) shad#0 already has a copy of map of map->epoch. in this case, it > will just return its own copy of osdmap as a foreign_ptr. shard#n will > throw the `map` away, and keep the returned foreign_ptr<> instead in > its local map<epoch_t, foreign_ptr<osdmap_ref>>. but for returning a > proper *foreign_ptr<>*, we need to delegate this request to the one > who actually *owns* the osdmap. > 2) shard#0 does not has the map yet. it will add the new osdmap to > its map<epoch_t, foreign_ptr<osdmap_ref>>, and return > foreign_ptr<osdmap_ref>. shard#n can tell if it actually owns the > returned map by checking get_owner_shard(). This sounds like the simpler model to me! > * symmetric model: everyone is the client and everyone is the server. > when shard#n gets an osdmap of epoch m, which it does not possess yet, > it will keep it in a map<epoch_t, lw_shared_ptr<> after querying all > shards for a map of epoch m, and nobody replies with a non-null > foreign_ptr<>. when shard#n needs the osdmap of epoch m, it sends the > following message to all its peer shards in parallel: > future<foreign_ptr<osdmap_ref>> get(epoch_t epoch). > > in both mode, we might want to avoid refcounting foreign_ptr<> > locally. and only delete it when we trimming this certain osdmap. > > 2. regarding to the interface between bluestore (objectstore) and the > rest part of osd, we could have something like: > seastar::future<RetVal> ObjectStore::submit_transaction(Transaction&& txn) I think we need new futures, one for when the transaction is applied/onreadable, and one for when it is committed and durable, since the write may involve reading some metadata. sage > 3. the CephContext in ObjectStore, we need a *copy* of the ConfigValue > which is registered as an observer which is updated by config proxy in > Seastar world. so we don't need to worry about reading a dirty option > being updated by a Seastar thread. > > > > -- > Regards > Kefu Chai > >
