On Fri, Dec 13, 2019 at 8:51 AM Mykola Golub <to.my.trociny@xxxxxxxxx> wrote: > > On Wed, Dec 11, 2019 at 08:41:10AM -0500, Jason Dillaman wrote: > > On Tue, Dec 10, 2019 at 11:02 PM Li Wang <laurence.liwang@xxxxxxxxx> wrote: > > > > > > Hi Jason, > > > If possible to do the following optimization, > > > (1) For write, update in memory map first, then write data and > > > asynchrously update map, > > > therefore will not have the first write performance problem > > > (2) For rbd open, after exclusive lock acquired, before loading the map, > > > write a flag MAP_IN_USE into the rbd header > > > (3) Before releasing exclusive lock, flush pending map writes, clean the flag > > > (4) For rbd open, if the flag exists before loading map, discard and > > > rebuild the map > > > > Changing the behaviour like this would break backwards compatibility > > with older clients. Therefore, it would really need a new feature bit > > to describe "object-map v2". Rebuilding the map on a large image is > > not a "free" operation since you might have to loop through tens of > > thousands of objects. That could be quite the unexpected surprise for > > a user attempting to restart a failed VM. > > Could mark the map as invalid on open and start rebuilding in > background? Yes, you could mark it invalid upon open as a workaround. You really wouldn't be able to effectively batch multiple object-map updates into a single op unless it was sequential writes, so overall you would still be limited to the 2-3K ops/sec that the OSDs can provide per object in the optimal case. I would think you would not want to automatically start an object-map rebuild (w/o an opt-in to the feature or at least until the OSDs support QoS to mark the rebuild ops as background work). > > -- > Mykola Golub > -- Jason _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
