On Mon, Dec 20, 2021 at 2:52 PM Wols Lists <[email protected]> wrote: > > And it might also mean blocking writes, which is why you don't want it > on spinning rust. But it also means that it is (almost) guaranteed to > get to permanent storage, which is why you do want it for mail, > databases, etc. >
The reason that mail/databases/etc use synchronous behavior isn't because it is "almost" guaranteed to make it to storage. The reason they use it is because you have multiple hosts, and each host can guarantee non-loss of data internally, but synchronous behavior is necessary to ensure that data is not lost on a handoff. Take a mail server. If your SMTP connection goes down for any reason before the server communicates that the mail was accepted then the sender will assume the mail was not delivered, and will try again. So if the network goes down, or the SMTP server crashes, then the client will cache the mail and try again. Most mail servers will have the data already on-disk before even attempting to deliver mail, so even if all the computers involved go down during this handoff nothing is lost as it is still in the client cache on-disk. On the other hand, once the server confirms delivery then responsibility is handed off and the client can forget about the mail. It is important that the mail server not communicate that the mail was received until it can guarantee that it won't lose the mail. That is usually accomplished by the server syncing the mail file to the on-disk spool and blocking until that is successful before communicating back to the client that the mail was delivered. Database transactions behave similarly. If the userspace application either does a write on a file opened with O_SYNC or does an fsync system call on the file, and the system call returns, then the data is present on-disk and will be persistent even if the power is lost at the very next moment. It is acceptable for a filesystem to return the call if the data is in a persistent journal, which is what the ZIL is, as long as it is flushed to disk. Of course, you can still accept mail or implement a database asynchronously, but you lose a number of data protections that are otherwise designed into the software (well, assuming you're not storing your data in MyISAM...). :) -- Rich
