Consequências TRIM

Eu queria saber se um de vocês pode me ajudar a entender o que o comando SSD TRIM realmente faz no Windows. Para o meu melhor conhecimento, uma vez que um usuário exclui um arquivo, o Windows obtém a lista de clusters ocupados pelo arquivo e os apaga da Tabela de Alocação de Arquivos. No entanto, a entrada de diretório permanece inalterada (nome do arquivo, registro de data e hora, etc.).

Como a deleção da célula flash é lenta, o SSD mantém uma lista de células livres nas quais pode gravar primeiro, e somente quando não houver mais células livres, inicia a exclusão de células marcadas para exclusão. O controlador não sabe se a célula está preenchida com zeros ou contém algo, entra no comando TRIM.

Se o comando TRIM permitir que o sistema operacional notifique o controlador sobre as células prontas para exclusão, uma vez chamado, o controlador não apenas "excluirá" a célula, mas removerá seu conteúdo.

Se isso for verdade, como funciona a recuperação no SSD?

Obrigado, atm

O TRIM faria a mesma coisa no Windows como em todos os outros sistemas operacionais. É um comando para o SSD (ou outro dispositivo que o suporte), na maior parte apenas passado como está pelo sistema operacional.

Primeiro, existem duas propriedades do flash que são importantes aqui:

• Ler e escrever flash é rápido, mas o apagamento é lento.
• Um determinado bloco só pode ser apagado um certo número de vezes antes de se desgastar.

Isso é muito diferente da mídia magnética: a mídia magnética não possui tal conceito como apagar (escrever efetivamente apaga o que estava lá antes), e não importa quantas vezes você sobrescreve o mesmo bloco (na verdade, reescrevendo um bloco, se tem qualquer efeito detectável, é um Boa coisa porque reforça o campo magnético).

A melhor maneira de usar o flash é usar um sistema de arquivos como jffs2 ou ubifs projetado para isso, aproveitar o fato de que o flash pode ser gravado incrementalmente (embora não seja apagado incrementalmente) e executa o nivelamento de desgaste no dispositivo (tentativas de apagar cada bloco um número aproximadamente igual de vezes).

Mas SSDs, cartões SD, pendrives e quase todos os outros tipos de dispositivos de bloco flash não permitem que você use esses sistemas de arquivos específicos para flash corretamente, porque existe o que chamamos de camada de translação flash entre o flash bruto e a interface do dispositivo de bloco. Essa camada não pode ser contornada e emula um dispositivo de bloco tradicional (magnético) na parte superior do flash. Ele implementa o nivelamento de desgaste necessário, espalhando blocos virtuais do dispositivo de bloco emulado sobre diferentes locais físicos de uma maneira que varia cada vez que um bloco é reescrito. Ele também permite que o dispositivo de bloco virtual tenha um tamanho de bloco pequeno que se assemelha ao tamanho de bloco dos dispositivos de bloco tradicionais (algo como 512 bytes ou 4096 bytes), embora o tamanho de um bloco físico de apagamento de flash seja muito maior (geralmente 128KBytes).

No caso mais simples, o FTL (flash translation layer) tem que fazer o seguinte trabalho toda vez que você escreve um bloco no dispositivo de bloco virtual, assumindo um tamanho de bloco de 128KB e um tamanho de bloco virtual de 4KB:

• Leia um bloco físico inteiro (que contém 32 blocos virtuais)
• Substitua o que você está escrevendo com novos conteúdos e mantenha os outros 31 como estão
• Apague um novo bloco de flash em algum lugar no dispositivo (ou use um que já tenha sido apagado recentemente)
• Escreva este novo conjunto de 32 blocos virtuais nele.

Os FTLs reais fazem muitas otimizações inteligentes para evitar ter que fazer esse processo completo com freqüência, então não é tão ruim quanto isso faz parecer. Mas, independentemente disso, o trabalho da FTL envolverá, em algum momento, a reescrita de novas cópias de blocos não relacionados quando algum outro bloco for escrito.

O problema é que isso às vezes é um desperdício de trabalho! O FTL não sabe quais blocos estão em uso e quais blocos estão livres. Esse é o trabalho do sistema de arquivos que fica no topo do dispositivo de bloco virtual. Não há necessidade de reescrever cópias de blocos que são realmente livres, porque ninguém se importará se o conteúdo desses blocos for alterado durante o processo de uma das operações de remapeamento e reescrita da FTL. Se ao menos houvesse uma maneira de dizer ao FTL quais blocos virtuais ele não precisa se preocupar com a preservação. Bem, esse caminho existe e chama-se TRIM. O TRIM salvará seu flash permitindo que o FTL apague e reescreva os blocos com menos frequência.

Agora, com este pano de fundo, para sua pergunta: como funciona a recuperação no SSD?

Bem, o sistema de arquivos que fica acima do FTL não deveria estar TRIMINANDO qualquer bloco que ele ainda precise acessar, então eu realmente não vejo a relevância da questão. Se o sistema de arquivos tiver erros, então, bem, a recuperação dependerá em grande parte do quão ruim é o bug, eu acho. Mas não há dúvida de que, com ou sem o TRIM, a complexidade adicional da camada FTL certamente tornará a recuperação da corrupção mais difícil sob algumas circunstâncias, por exemplo, se as informações de mapeamento virtual-físico do FTL ficarem corrompidas.