Trimcheck, è vero, inserisce una verifica diretta per provarne inequivocabilmente il risultato. Ma in questo
caso mi sembra che la fretta non sia stata d'aiuto: la soluzione era ampiamente a portata ... d'occhio :-)
Tra la finalizzazione del comando TRIM alla effettiva cancellazione dei dati contenuti nei blocchi trimmati
passa necessariamente un tot periodo di tempo. Tale periodo non è temporalmente fisso ma dipende
sostanzialmente da un algoritmo definito nello standard ed è comunque legato alle attività di lettura
di quel determinato dataset da parte del s.o., successive alla finalizzazione del comando TRIM stesso:
http://www.t13.org/documents/UploadedDocuments/docs2008/e08137r4-DRAT_-_Deterministic_Read_After_Trim.pdf
http://www.t10.org/ftp/t10/document.08/08-149r4.pdf
http://www.t10.org/ftp/t10/document.08/08-341r0.pdf
http://ftp.t10.org/ftp/t10/document.08/08-341r2.pdf
http://www.t10.org/ftp/t10/document.08/08-356r0.pdf
http://t10.org/ftp/t10/document.08/08-149r2.pdf
etc.
quest'ultimo documento spiega perfettamente bene tutto l'iter logico che la commissione ha dovuto
affrontare per giungere a delle determinazioni di come creare l'algoritmo più utile, salvaguardando
anche la sicurezza e la privacy dei dati contenuti nei blocchi da trimmare
http://www.t10.org/ftp/t10/document.08/08-347r1.pdf
non te la prendere, sono curioso: quali sarebbero le porcherie che Asus inserirebbe nei driver ufficiali Intel :-)
Ciao Toto, quello che ci ha tratto in inganno è stato proprio il tempo necessario al Predator per eseguire il TRIM.
Ho aspettato ben più di 20 secondi e neanche dopo un paio di riavvii era stato eseguito il comando, ci sono voluti circa 3-4 minuti di attesa in idle perché il TRIM si attivasse.
Facendo invece una prova con un Samsung 850 EVO e poi con un Vector 180 l'esecuzione di tale comando era pressoché immediata.
Carlo, non dovresti sentirti parte in causa, se non in maniera estremamente marginale :-):
1) perché ti sei accorto autonomamente della circostanza, sebbene stessi solo rispondendo ad un
quesito ben circostanziato
2) perchè il tuo interlocutore (RaptorX86) avrebbe dovuto avere già bene in mente le attività e le
indicazioni dello sviluppatore di TrimCheck, essendone a suo dire ben in fiducia ed avendone già
potuto/dovuto sviscerare in precedenza le caratteristiche (e le indicazioni a video).
i tre ssd sono stati utilizzati nelle medesime condizioni operative al momento del TRIM?
Presentavano analoga percentuale di spazio disponibile/utilizzato?
L'ultimo secure erase portato a termine su ognuno?
Oltretutto, l'850 EVO ed il Vector 180 sono dispositivi di tipologia, classe e target prestazionale ben
differenti rispetto al Predator: i produttori non utilizzano le medesime strategie di Wear Leveling su
tutti i propri modelli.
Ritengo che Kingston abbia ritenuto opportuno usare sul Predator una strategia di WL sensibilmente
più conservativa, in modalità statica, per aumentare le aspettative di vita del dispositivo: è facile in
qualche modo intuire che il Predator, essendo già molto veloce di suo, non aveva bisogno di una
ulteriore mano in tal senso.
Credo pertanto che sia proprio questa circostanza che abbia di fatto portato, come conseguenza
diretta, ad una ponderata dilatazione della frequenza di finalizzazione delle attività in questione.
Kingston ha reso disponibile già da qualche tempo una utility per la gestione dei suoi SSD denominata, per l'appunto, Kingston SSD Manager.
Di seguito vi posto le quattro schermate principali che questo software mette a disposizione, tra cui, l'aggiornamento del firmware che, attualmente è arrivato alla versione OC34L5TP.
Questo è il link per scaricare il suddetto software e l'apposita guida per l'utilizzo.
Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando
