An LBA (logical block addresses) is a mapping table implemented in the FTL to match between logical and physical pages/blocks in SSDs, my guess is that most SSDs (at least when they are empty) keeps the physical addresses in the same order as the logical ones (the physical address 0 is mapped with the logical address 0, 1 with 1 and so on).

When a page is changed the SSD controller copy the updated page to the cache, changes the page, mark the old one as 'none valid / stale' and then write the new one in a different location and update the LBA.

So, after a couple of writes even if the physical addresses were aligned with the logical ones, this order will be messed up!

Why does sequential writes have better performance than random writes then?


The lack of performance between sequential and random writes was regardless of the block size or the queue depth.

  • 1
    why down voting !!, it is a perfectly reasonable question, a lots of confusing interpretation out there !!
    – SamTh3D3v
    Apr 10, 2017 at 10:26
  • 4
    By philosophy and design votes are anonymous and neither voting up nor voting down requires any mandatory explanation. The tooltip that appears when your mouse pointer hoovers over the down button states: "this question does not show any research effort; it is unclear or not useful". Also questions can attract a down vote when not well written, not quite on-topic or missing details.
    – HBruijn
    Apr 10, 2017 at 11:15
  • @Elhamer I downvoted because I can't figure out what you're talking about. When you say "random writes", do you mean random 4KB writes? Or random writes equal in size to the SSD's native block size? Do you mean one at a time? Or with some queue depth? Apr 10, 2017 at 21:21
  • @DavidSchwartz well i didn't mention the size nor the queue depth because i encountered the same lack of performance between random and sequential writes regardless of the other parameters (4k, 128k etc..), QD (16, 32)
    – SamTh3D3v
    Apr 10, 2017 at 21:25

2 Answers 2


A reasonably concise explanation by Seagate on how garbage collection is responsible for the difference in SSD performance for random versus sequential writes:

... the need for garbage collection affects an SSD’s performance, because any write operation to a “full” disk (one whose initial free space or capacity has been filled at least once) needs to await the availability of new free space created through the garbage collection process. Because garbage collection occurs at the block level, there is also a significant performance difference, depending on whether sequential or random data is involved. Sequential files fill entire blocks, which dramatically simplifies garbage collection. The situation is very different for random data.

As random data is written, often by multiple applications, the pages are written sequentially throughout the blocks of the flash memory.
The problem is: This new data is replacing old data distributed randomly in other blocks. This causes a potentially large number of small “holes” of invalid pages to become scattered among the pages still containing valid data. During garbage collection of these blocks, all valid data must be moved (i.e. read and re-written) to a different block.
By contrast, when sequential files are replaced, entire blocks are often invalid, so no data needs to be moved. Sometimes a portion of a sequential file might share a block with another file, but on average only about half of such blocks will need to be moved, making it much faster than garbage collection for randomly-written blocks. ...

  • Yes, that makes sense, thank you. But the thing that's bothering me is the fact that sequential read will read data pages based on how they are mapped on the LBA. If a page got updated, its logical address will remain but it's physical address will be changed (since updating a page consist of rewriting it in a free space and mark the old one as stale for GC), based on that after a couple of random updates, physical sequential writes can't really be performed on the physical level (which should be the case most the times)!
    – SamTh3D3v
    Apr 10, 2017 at 12:17

Another explanation is that sequential I/Os are easier to coalesce at all levels. Generally you have less overhead when you send the same data but using fewer but bigger I/Os thus you can reach a higher throughput by coalescing. You would have to prove whatever kernel you were using didn't batch your sequential I/Os up into bigger I/Os thus reducing overhead and improving the performance in comparison to what it had to do for random I/O.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.