• 5

A PHP Error was encountered

Severity: Notice

Message: Undefined index: userid

Filename: views/question.php

Line Number: 191


File: /home/prodcxja/public_html/questions/application/views/question.php
Line: 191
Function: _error_handler

File: /home/prodcxja/public_html/questions/application/controllers/Questions.php
Line: 433
Function: view

File: /home/prodcxja/public_html/questions/index.php
Line: 315
Function: require_once

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
    • @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)
      • 1
    • @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?

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. ...

  • 9
Reply Report
      • 2
    • 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)!

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.

  • 1
Reply Report

Trending Tags