Sua lógica não está incorreta. Mas isso só é válido se algumas condições forem atendidas.
O comando TRIM , conforme especificado no conjunto de comandos ATA , pode ou não zerar os setores nos quais é emitido.
Na verdade, o padrão se concentra em quais dados devem ser retornados após a emissão do TRIM 1 :
Os seguintes comportamentos são especificados por este padrão para setores que o dispositivo apara (consulte 7.5.3.3):
a) não determinístico - os dados em resposta a uma leitura de um setor aparado podem mudar para cada leitura até que o setor seja gravado pelo host;
b) Leitura determinística após recorte (DRAT) - os dados retornados em resposta a uma leitura de um setor recortado não mudam, mas podem ser diferentes dos dados retornados anteriormente; e
c) Ler zeros após aparar (RZAT) - os dados retornados em resposta a uma leitura do setor aparado são zero.
[...] Para dispositivos de armazenamento DRAT e não determinísticos, os dados retornados em resposta a um comando de leitura para um LBA que foi aparado com êxito:
a) podem ser os dados retornados anteriormente para o LBA especificado;
b) pode ser um padrão gerado pelo dispositivo de armazenamento; e
c) não é dados previamente gravados em um LBA diferente pelo hospedeiro.
Assim, o que o seu dispositivo retorna depois fstrimdepende dos recursos implementados. A menos que ele suporte RZAT, a suposição de que os dados lidos de um dispositivo aparado serão apenas zeros não é válida.
Você pode usar hdparmpara verificar isso:
sudo hdparm -I /dev/sdX | grep -i trim
Eu realizei alguns testes usando dois SSDs sdae sdb. Mesmo fabricante, modelos diferentes, com conformidade ATA diferente:
$ sudo hdparm -i /dev/sdb
...
Drive conforms to: Unspecified: ATA/ATAPI-3,4,5,6,7
...
$ sudo hdparm -i /dev/sda
...
Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7
...
Os dois SSDs têm suporte diferente para TRIM:
$ sudo hdparm -I /dev/sda | grep -i trim
* Data Set Management TRIM supported (limit 1 block)
$ sudo hdparm -I /dev/sdb | grep -i trim
* Data Set Management TRIM supported (limit 8 blocks)
* Deterministic read ZEROs after TRIM
Posso confirmar que, após a emissão fstrim, a unidade que suporta "ZEROs de leitura determinística após TRIM" (RZAT) parece realmente zerar a partição em questão quase inteiramente. Por outro lado, a outra unidade parece ter zerado (ou substituído por algum padrão altamente compressível) apenas uma parte menor do espaço liberado.
1 Fonte online: INCITS 529: Tecnologia da informação - Conjunto de comandos ATA / ATAPI - 4 (ACS-4)
Nota sobre o teste:
Conforme indicado por frostschutz nos comentários, uma leitura posterior fstrimpode retornar dados do cache do sistema operacional e não do dispositivo aparado. É, por exemplo, o que aconteceu nesta pergunta .
(Eu também apontaria essa resposta para a mesma pergunta, para um método alternativo para testar o TRIM).
Entre fstrime uma leitura subsequente, pode ser necessário descartar o cache, por exemplo, com:
echo 3 | sudo tee /proc/sys/vm/drop_caches
Dependendo do tamanho da partição com a qual você está reproduzindo, não soltar o cache pode ser suficiente para que seus testes falhem.
Nota sobre sua configuração:
A discardopção de montagem ativa o TRIM contínuo, ou seja, quando os arquivos são excluídos. Não é exigido por fstrim. De fato, o TRIM sob demanda e o TRIM contínuo são duas maneiras distintas de gerenciar as operações do TRIM. Para mais informações, aponto para a unidade de estado sólido no Arch Linux Wiki, que possui uma cobertura detalhada desse assunto.
dmsetup table | grep allow_discards