Por que as gravações sequenciais têm melhor desempenho que gravações aleatórias em SSDs?

4

Um LBA (endereços de bloco lógico) é uma tabela de mapeamento implementada no FTL para corresponder entre páginas / blocos lógicos e físicos em SSDs , meu palpite é que a maioria dos SSDs (pelo menos quando estão vazios) mantém os endereços físicos na mesma ordem que os lógicos (o endereço físico 0 é mapeado com o endereço lógico 0, 1 com 1 e assim por diante).

Quando uma página é alterada, o controlador SSD copia a página atualizada para o cache, altera a página, marca o antigo como ' none válido / obsoleto 'e, em seguida, escreva o novo em um local diferente e atualize o LBA.

Então, depois de algumas gravações, mesmo que os endereços físicos estejam alinhados com os lógicos, esse pedido será confuso!

Por que as gravações seqüenciais têm melhor desempenho que gravações aleatórias?

Editar

A falta de desempenho entre gravações sequenciais e aleatórias foi independente do tamanho do bloco ou da profundidade da fila.

    
por SamTheDev 10.04.2017 / 11:52

2 respostas

6

Uma explicação razoavelmente concisa por Seagate sobre como a coleta de lixo é responsável pela diferença no desempenho do SSD para gravações aleatórias versus sequenciais:

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

    
por 10.04.2017 / 13:14
1

Outra explicação é que as E / S sequenciais são mais fáceis de unir em todos os níveis. Geralmente, você tem menos sobrecarga ao enviar os mesmos dados, mas usando menos E / Ss maiores, portanto, você pode alcançar uma taxa de transferência maior por meio de coalescência. Você teria que provar que o kernel que estava usando não aumentava o E / S sequencial em E / Ss maiores, reduzindo assim a sobrecarga e melhorando o desempenho em comparação com o que ele tinha que fazer para E / S aleatória.

    
por 05.04.2018 / 11:05