This design ACKs writes that aren't yet durably persisted (to the journal or data areas). That might be ok, but it might not. It's certainly unusual not to at least persist the journal update.

▲

zzsheng 4 days ago | parent [-]

nop. we will not ack any write which is not in data or journal. please check the put details in the blog.

▲

loeg 4 days ago | parent [-]

You initiate a write to the journal, but do not sync it before ACKing to the client.

▲

zzsheng 4 days ago | parent [-]

journal file was pre-alloacated and we use direct-io for journal write so no need to call fsync.

▲

loeg 4 days ago | parent | next [-]

Again, it is not durably persisted before acking to the client. Like I said earlier, that might be fine for your durability model, but it is unusual.

	▲	thomas_fa 4 days ago \| parent [-]
		We would wait for Bss data and journal DirectIO and the acking (sending response back to api_server) in the callback function. What you are implying is what s3 actually doing and you can get see from their paper[1] and we are stronger than that. [1]https://www.amazon.science/publications/using-lightweight-fo....

▲

4 days ago | parent | prev [-]

[deleted]