From d9533c3c508fbda5a80ec5dcbf80c1b0badc0e4c Mon Sep 17 00:00:00 2001 From: Tyler Neely <1505488+spacejam@users.noreply.github.com> Date: Thu, 4 Jan 2024 23:57:50 +0100 Subject: [PATCH] Update ARCHITECTURE.md Co-authored-by: Amar Singh --- ARCHITECTURE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index d309931c..94993d50 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md @@ -59,7 +59,7 @@ 1. Fsync of the metadata log directory. 1. After the atomic metadata batch write, the previously occupied slab slots are marked for future reuse with the epoch-based reclamation system. After all threads that may have witnessed the previous location have finished their work, the slab slot is added to the free `BinaryHeap` of the slot that it belongs to so that it may be reused in future atomic write batches. 1. Return `Ok(())` to the caller of `Db::flush`. -* Writing objects before the metadata write is random, but modern SSD's handle this well. Even though the SSD's FTL will be working harder to defragment things periodically than if we wrote a few megabytes sequentially with each write, the data that the FTL will be copying will be mostly live due to the eager leaf write-backs. +* Writing objects before the metadata write is random, but modern SSDs handle this well. Even though the SSD's FTL will be working harder to defragment things periodically than if we wrote a few megabytes sequentially with each write, the data that the FTL will be copying will be mostly live due to the eager leaf write-backs. ## recovery