time for cyrus-imap v3.2?

[Anatoli]

Bron,

The proposed algo is a barrier before any single-lock. In itself it's a
single lock, but the same code (the pseudocode for the *worker thread*
in my previous mail) should be inserted at *every* single-lock/write
operation location. If there's no need to pause, the overhead is
non-existent. If a pause is requested, all worker threads would pause at
the entrance to any single-lock/write code.

It would make the entire Cyrus daemon to complete all pending write
operations and pause new ones. At this stage, if I understand it
correctly, the data on disk would be in a consistent state, ready to
take a snapshot or to perform some other operation.

Without that, if we just take a snapshot of the fs, it could happen that
a) some files are not written entirely (i.e. caught in the middle of a
write operation) or b) the contents of some files are newer than the
other, i.e. the logical write operation was not atomic (e.g. mail data
is written but indexes are not updated yet or something similar).

Maybe I didn't understand you correctly. Do you mean that finishing all
writes and pausing new ones is not enough to guarantee an integral state
of files on disk? If it's the case, what would have to be done to
guarantee it (i.e. to make it like Cyrus was shutdown normally)?

Regards,
Anatoli

On 7/11/19 19:56, 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.
> 
> Bron.
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong at fastmailteam.com
> 
>