La tua logica non è errata. Ma è valido solo se alcune condizioni sono soddisfatte.
Il comando TRIM , come specificato nel set di comandi ATA , può azzerare o meno i settori nei quali viene emesso.
In realtà, lo standard si concentra su quali dati devono essere restituiti dopo l'emissione di TRIM 1 :
I seguenti comportamenti sono specificati da questo standard per i settori che il dispositivo taglia (vedi 7.5.3.3):
a) non deterministico: i dati in risposta a una lettura di un settore tagliato possono cambiare per ogni lettura fino a quando il settore non viene scritto dall'host;
b) Deterministic Read After Trim (DRAT): i dati restituiti in risposta a una lettura di un settore tagliato non cambiano, ma possono essere diversi dai dati precedentemente restituiti; e
c) Leggi zero dopo il trim (RZAT): i dati restituiti in risposta a una lettura del settore tagliato sono zero.
[...] Per entrambi i dispositivi di archiviazione DRAT e non deterministici, i dati restituiti in risposta a un comando di lettura a un LBA che è stato tagliato con successo:
a) possono essere i dati precedentemente restituiti per l'LBA specificato;
b) può essere un modello generato dal dispositivo di memorizzazione; e
c) non sono dati precedentemente scritti in un diverso LBA dall'host.
Pertanto, ciò che il dispositivo restituisce dopo fstrimdipende dalle funzionalità implementate. A meno che non supporti RZAT, il presupposto che i dati letti da un dispositivo tagliato siano solo zeri non è valido.
Puoi usare hdparmper verificare questo:
sudo hdparm -I /dev/sdX | grep -i trim
Ho eseguito alcuni test usando due SSD sdae sdb. Stesso produttore, diversi modelli, con diversa conformità ATA:
$ 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
...
I due SSD hanno un supporto diverso per 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 confermare che, dopo l'emissione fstrim, l'unità che supporta "Lettura deterministica ZERO dopo TRIM" (RZAT) sembra aver effettivamente azzerato quasi interamente la partizione interessata. Al contrario, l'altra unità sembra aver azzerato (o altrimenti sostituito con qualche modello altamente comprimibile) solo una parte minore dello spazio liberato.
1 Fonte online: INCITS 529: Tecnologia dell'informazione - Set di comandi ATA / ATAPI - 4 (ACS-4)
Nota sui test:
Come sottolineato da frostschutz nei commenti, un read read fstrimpuò restituire dati dalla cache del sistema operativo e non dal dispositivo tagliato. È, ad esempio, ciò che è accaduto in questa domanda .
(Vorrei anche indicare questa risposta alla stessa domanda per un metodo alternativo per testare TRIM).
Tra fstrimuna lettura successiva e la successiva potrebbe essere necessario eliminare la cache, ad esempio con:
echo 3 | sudo tee /proc/sys/vm/drop_caches
A seconda delle dimensioni della partizione con cui stai giocando, non far cadere la cache potrebbe essere sufficiente per il fallimento dei test.
Nota sulla configurazione:
L' discardopzione mount abilita il TRIM continuo, ovvero ogni volta che i file vengono eliminati. Non è richiesto da fstrim. In effetti, TRIM su richiesta e TRIM continuo sono due modi distinti per gestire le operazioni TRIM. Per ulteriori informazioni vorrei indicare l'unità a stato solido sul Wiki di Arch Linux, che ha una copertura dettagliata di questa questione.
dmsetup table | grep allow_discards