Posso emular o TRIM escrevendo todos os zeros?

Question

Antes de um setor de SSD ¹ ser escrito, parece que tudo está preenchido com zeros.

Então, se eu escrever todos os zeros em um setor, com a finalidade de funcionalidade, ele será parecido com um livre. Assim, o controlador tem uma possibilidade técnica de tratá-lo como tal. Meu conhecimento limitado da arquitetura do IC diz que a desaceleração do hardware de um teste de circuito para todos os zeros provavelmente seria desprezível, se é que existe algum.

A pergunta é: algum controlador flash / SSD realmente implementa isso ou algo semelhante?

Parece ainda mais aplicável ao armazenamento de memória flash conectado por meio de interfaces que não têm o comando TRIM, como USB.

Nas respostas postadas até agora, algumas pessoas delinearam possíveis problemas no show-stopper. No entanto, todos acabaram por não ser problemas. A menos que exista evidência de que aqueles realmente são problemas sérios, por favor, não afirme com autoridade que eles são, mas honestamente, diga que você está apenas supondo que isso é verdade.

¹ _{Um setor lógico, ou seja, o que o host vê.}

    

Answer 1

Na verdade, um setor de SSDs apagados é preenchido com uns, não com zeros. Você está confundindo setores de SSD (os setores físicos reais no SSD que queremos cortar) com setores de disco (os setores lógicos que o SSD apresenta ao sistema de arquivos depois que ele é executado com sua mágica de gerenciamento). O preenchimento de setores lógicos com zero não seria necessário, uma vez que forçaria o SSD a alocar setores físicos SSD apagados e preenchê-los com zeros.

Quando um setor lógico é aparado, o SSD desmata qualquer setor físico mapeado para esse setor lógico. Quando tem uma chance, apaga-os, o que os preenche com 1's. Uma vez apagados, eles são adicionados a um conjunto de setores físicos apagados. O objetivo do corte é ampliar o conjunto de setores físicos apagados.

Quando você lê um setor lógico que não possui setor físico correspondente, a unidade retorna uma página de zeros. Mas não precisa ler nenhum setor físico para fazer isso, nem poderia, já que nenhum setor físico é mapeado.

Veja aqui para mais detalhes.

    

Answer 2

Can I emulate TRIM by writing all zeros?

Não.
O ato de escrever requer um setor apagado e, em seguida, ocorre a operação de gravação real. A operação de gravação é uma indicação para o SSD que este setor está em uso (a condição oposta que você quer com um comando TRIM real).

Before an SSD sector was ever written to, it looks like all filled with zeros.

Incorreto e, aparentemente, sua pergunta é baseada nessa premissa falsa.
Um setor apagado é preenchido com bytes de 0xFF (todos os outros).

Um formato tradicionalmente escreve todos os zeros em todos os setores.

So, if I write all zeros to a sector, for the purpose of functionality, it will look just like a free one.

Não, não vai.
Tenha em atenção que existem sectores "livres" ao nível do sistema de ficheiros e sectores "livres" ao nível da SSD. Em teoria, eles devem ser o mesmo conjunto, mas como o SSD tem que ser explicitamente informado pelo sistema de arquivos que um setor é "livre" (com um comando TRIM), existem discrepâncias.

ADENDO

Thus the controller has a technical possibility to treat it as such. My limited knowledge of IC architecture says that hardware-wise, slowdown from a circuit testing for all zeros would probably be negligible, if any at all.

The question is: does any flash/SSD controller actually implement this or anything similar?

Não, porque isso levaria a perda de dados não intencional.
Sempre que um programa escrevesse um setor de todos os zeros (por exemplo, uma imagem de memória pode ter tais blocos), seu esquema permitiria que o SSD descartasse esse setor, já que o trataria como um setor não mapeado, em vez de um setor em uso e alocado para um arquivo.

Resumindo, seu esquema proposto (usando conteúdo de dados) não funciona.
Se você deseja designar um setor como livre ou não usado, há o comando TRIM.
Não há operação de gravação substituta.

    

Answer 3

Can I emulate TRIM by writing all zeros?

Não.

Veja como o flash funciona:

• O flash não-gravado é todo de 1 e escreve os números 1 a 0.

• O Flash é escrito em uma quantidade de bytes conhecida como página , sendo 2048 bytes um exemplo de tamanho de página. (Há também uma pequena quantidade de dados - 64 bytes ou mais, que também faz parte dessa página onde as informações do ECC podem ser armazenadas)

• E se você quiser alterar 0 de volta para 1? Você não pode, a menos que você apague a página.

• Quando você apaga o flash - que inverte todos os bits para 1 se a página não estiver danificada, a quantidade de bytes que você pode apagar (o tamanho eraseblock para usar a terminologia do Linux) é tipicamente maior que o tamanho da página. 128k sendo um exemplo de tamanho de um apagamento.

• A eliminação demora muito mais tempo do que apenas escrever para uma página.

Então, porque:

• Os SSDs fingem que são discos rígidos padrão para o host. Os discos rígidos padrão funcionam em setores de 512 bytes (chamados de LBAs e numerados como 0 na capacidade do drive dividido por 512), não em 2048 ou em qualquer outro tamanho;

• e o firmware do SSD tem que fazer muito falso em segundo plano, pois não existem locais de 512 bytes para armazenar os dados, como em um disco rígido giratório;

• e escrever para uma página que não precisa ser apagada é mais rápido do que apagá-la e, em seguida, escrever para ela.

Os SSDs mantêm algo chamado de tabela LBA para PBA. O sistema operacional, por exemplo, diz ao SSD para escrever no LBA 20, mas pode realmente entrar em algo como "Flash chip 2 página 56". Isso é mantido na tabela LBA para PBA.

O firmware do SSD tentará direcionar gravações para páginas novas e evitar o apagamento, a menos que seja necessário. Se nenhuma página não escrita estiver disponível, ela terá que misturar as coisas e fazer uma leitura / talvez escrever em algum outro lugar / apagar / escrever um monte de ciclos de coisas.

Assim, a tabela LBA para PBA pode ser completamente aleatória.

O TRIM informa ao SSD que ele pode remover entradas desta tabela (ou marcar como "LBA ainda não gravado") e realmente apagar algum flash e disponibilizá-lo para gravações rápidas no futuro.

Portanto, é por isso que escrever todos os 0x00s ou 0xFFs não é equivalente. Somente o TRIM informa ao firmware que está tudo bem para não rastrear as coisas nessa tabela e considerar o flash não utilizado - e apagá-lo em preparação para novas gravações.

Escrevendo todos os resultados de 0x00 ou 0xFF em uma tabela LBA-para-PBA completa que está rastreando os dados que acha que você está usando e as coisas permanecerão lentas devido à necessidade de reorganizar as coisas e ler / apagar / reescrever.