Rewrite lock. Lock a data, then write it, then release the lock.
copy-on-write, copy the data into a new place, update the date in new place. Then update the data’s reference to the new place.
Rewrite lock. Lock a data, then write it, then release the lock.
copy-on-write, copy the data into a new place, update the date in new place. Then update the data’s reference to the new place.
WAL persistents operation to disk, then write to cache. If each operation needs to persistent to disk, then it is low efficient. Instead, do batching, this helps to improve performance, also reduce the error to batch level.
https://martinfowler.com/articles/patterns-of-distributed-systems/wal.html
Flushing every log write to the disk gives a strong durability guarantee (which is the main purpose of having logs in the first place), but this severely limits performance and can quickly become a bottleneck. If flushing is delayed or done asynchronously, it improves performance but there is a risk of losing entries from the log if the server crashes before entries are flushed. Most implementations use techniques like Batching, to limit the impact of the flush operation.