Bron Gondwana wrote: > On Thu, Nov 7, 2019, at 15:46, Anatoli via Cyrus-devel wrote: >> Bron, >> >> Thanks for your detailed reply and the work the FM team is doing! >> >> > This is not easy unfortunately with all the different datastructures, >> > because it means that everything else which takes a lock is going to >> > need to first take a global shared lock before it does anything else, >> > and that's going to have a performance and complexity impact on >> > everything - because you have to find them ALL or you might wind up >> > with lock inversions down the line. >> >> One solution I see is to have a separate single lock, not even a lock >> per se, but a barrier. I.e. before every write operation > > How does that maintain consistency? I guess you don't get skew between > files, but you still have to do crash recovery on every file. There's no > single place > to put this either. > > I think I still prefer the idea of a shared locks that wraps every single > other lock, such that taking the snapshot pauses every attempt to start a new > lock > until it's done, so you always get a completely clean read equivalent to a > clean shutdown.
Not to sound like a broken record, but - if you were using named databases in LMDB for all of these separate data structures, you would get atomic snapshots for free. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/