Tutto sugli SSD: notizie e modelli

[grosso999]

Ciao a tutti sto valutando l'acquisto di un ssd, me ne potete consigliare uno, considerando il rapporto prezzo/prestazioni, tra questi? :
SSD OCZ Vertex 2 60GB 79 €
SSD OCZ Agility 3 60GB 90,60 €
SSD OCZ Vertex 3 60GB 108,50 €
SSD Corsair Force F80A 80GB 111,70 €

Poi avrei anche qualche domanda da fare:
fra serial ata 2 e 3, a livello pratico, cambia tanto?
60 GB possono bastare?
Grazie

[JavaScript]

Ho dato un occhiata per vedere l'acculturatezza generale in fatto di SSD ed è uscito di tutto...

Se posso metterci i miei due centesimi suggerirei:

1°) Per quanto riguarda l'allineamento converrebbe sempre saltare il primo blocco fisico, o meglio quello che è considerato l' "ERASE BLOCK SIZE" , ovvero la dimensione minima di blocco che viene "fisicamente" maneggiato dal controller quando sposta dei dati, nei più recenti drive SandForce 2xxx generalmente (ma non sempre) è spesso di 512KB, un articolo interessante e chiaro in materia, anche se in inglese lo si può trovare qui, molto importante sarebbe conoscere con precisione la geometria delle celle sul proprio SSD in modo da calcolare bene sia l'allineamento fisico sia quello logico di partizioni e filesystem all'effettivo dislocamento dei wafer di condensatori ed alle impostazioni del controller, ma questo mi rendo conto che non è sempre considerato con la dovuta attenzione ed in ogni caso andrebbe molto più approfondito, tuttavia c'è una attuale enorme carenza di informazioni sulle specifiche fisiche e sulle configurazioni dei controller che non permette ancora di ottenere le migliori configurazioni possibili con facilità.

2°) Per tutti gli SSD, che supportino il comando TRIM o meno, è possibile effettuare una pulizia dei medesimi in modo da ripristinare le prestazioni eventualmente compromesse da garbage-collection e wear-leveling a causa della write amplification da queste implementazioni creata nel seguente modo:

(esempio per trimmare una unità "C:")

- installare Eraser-5.8.8 (solo questa versione) ottenibile da sourceforge
- configurare in preferenze (erasing) un nuovo profilo di cancellazione a pattern singolo, pieno di zeri, singolo passaggio e chiamarlo per coerenza "zero".
- creare un nuovo file in C:\ chiamato semplicemente "TRIM".
- configurare un nuovo task (manuale) in eraser settato per cancellare "files" e, nello specifico il file "C:\TRIM" utilizzando il metodo di cancellazione "zero" appena creato, selezionare la casella "mantieni nella lista" o "keep task on list".
- cancellare direttamente il file (vuoto) TRIM appena creato per testare che la configurazione di eraser sia corretta. (IMPORTANTE non selezionate MAI il metodo Gutmann se non volete accorciare di mesi la vita del vostro SSD in un colpo solo, solo ed esclusivamente il metodo "zero" appena creato)
- aprire un prompt dei comandi ed abilitare la modalità di modifica rapida (da "proprietà" della finestra).
- digitare --> fsutil volume diskfree C: (enter)
- delle tre linee visualizate selezionare con il mouse (con precisione) il valore corrispondente ai bytes totali considerati liberi dal sistema e cliccarci di destro sopra (questo copia il valore)
-digitare --> fsutil file createnew C:\TRIM (cliccare di destro per incollare il valore precedentemente copiato)
- al messaccio C:\TRIM file creato con successo tornate sui task di eraser e lancaiate manualmente il task appena creato, questa operazione richiederà un certo tempo e sovrascriverà di zeri tutto lo spazio allocato al file "C:\TRIM", ovvero tutto lo spazio considerato libero dal SISTEMA OPERATIVO indipendentemente dal fatto che fisicamente sul supporto siano presenti dati "spazzatura" in attesa di essere sovrascritti e/o riorganizzati dalla funzione garbage -collection, liberando di fatto tutto lo spazio libero e riportandolo allo stato di fabbrica

Per inciso un bit scritto su un SSD è una trappola ripiena di elettroni che viene letto 0 se al di sotto di un certo valore oppure 1 se al di sopra, scrivendo degli zeri in pratica si scaricano tutti i condensatori che devono essere scarichi lasciandoli, per la maggior parte in blocchi, nella condizione di poter essere riscritti immediatamente in quanto vuoti, alcune utility ed altri sistemi possono liberare lo spazion come lo farebbero su di un HDD, per esempio scrivendo il valore 20 che corrisponde ad uno spazio, visivamente il blocco è vuoto e per un HDD va benissimo, per un SSD corrisponde ad un pattern di 0 e 1 che per esso significa "blocco in uso->da riallocare->collezionare dati->rimappare in memoria->aggiungere nuovi dati->scrivere in un altra posizione considerata libera (che non esiste ed è quindi da creare con lo stesso sistema)", questo provoca un enorme write amplification ed un degrado delle prestazioni ancora peggiore dell'avere a che fare con blocchi pieni di 1 da spostare per intero.


Spero di aver reso l'idea, scusate se non ho potuto affinare meglio ma ho un impegno e nessuna voglia di copiare il messaggio per ripostarlo dopo.

Approfondiremo in seguito.

[TheDarkAngel]

Se scrivi "zero" i controller sandforce scriveranno qualche manciata di dati

[Trotto@81]

Originariamente inviato da JavaScript

Ho dato un occhiata per vedere l'acculturatezza generale in fatto di SSD ed è uscito di tutto...

Se posso metterci i miei due centesimi suggerirei:

1°) Per quanto riguarda l'allineamento converrebbe sempre saltare il primo blocco fisico, o meglio quello che è considerato l' "ERASE BLOCK SIZE" , ovvero la dimensione minima di blocco che viene "fisicamente" maneggiato dal controller quando sposta dei dati, nei più recenti drive SandForce 2xxx generalmente (ma non sempre) è spesso di 512KB, un articolo interessante e chiaro in materia, anche se in inglese lo si può trovare qui, molto importante sarebbe conoscere con precisione la geometria delle celle sul proprio SSD in modo da calcolare bene sia l'allineamento fisico sia quello logico di partizioni e filesystem all'effettivo dislocamento dei wafer di condensatori ed alle impostazioni del controller, ma questo mi rendo conto che non è sempre considerato con la dovuta attenzione ed in ogni caso andrebbe molto più approfondito, tuttavia c'è una attuale enorme carenza di informazioni sulle specifiche fisiche e sulle configurazioni dei controller che non permette ancora di ottenere le migliori configurazioni possibili con facilità.

Il blocco fisico è di 4096 byte e la prima partizione deve iniziare da un multiplo di esso, mi fermo qui perchè sto andando a farmi un bel bagno a mare.

[SteFerrari]

Originariamente inviato da marklevi

"like"

credo che il mioo sistema booti un po prima... le 4 lucine del logo di 7 non fanno in tempo a toccarsi che mi compare la schermata della password. ...

Lo usi in Sata 2 o 3 ?
Windows è completamente aggiornato ?
Il mio inizialmente era un attimino più veloce, poi una volta installati tutti i programmi ed anche il Service Pack 1 deve aver perso qualcosina, rimane comunque tutt'altra cosa rispetto al Raid 0 di HDD meccanici che avevo prima quindi sono comunque soddisfatto, eppoi è su Sata 2.

[Portocala]

Originariamente inviato da grosso999

Ciao a tutti sto valutando l'acquisto di un ssd, me ne potete consigliare uno, considerando il rapporto prezzo/prestazioni, tra questi? :
SSD OCZ Vertex 2 60GB 79 €
SSD OCZ Agility 3 60GB 90,60 €
SSD OCZ Vertex 3 60GB 108,50 €
SSD Corsair Force F80A 80GB 111,70 €

Poi avrei anche qualche domanda da fare:
fra serial ata 2 e 3, a livello pratico, cambia tanto?
60 GB possono bastare?
Grazie

Spendi quei 50 euro in più e prendi un M4 da 128GB.
Meno sbattimento di spazio in futuro e prestazioni superiori.

[marklevi]

per la cronaca, aggiornato il c300 a 007 senza problemi al sistema operativo ed applicativi 24GB di installazione, tempo totale 5 minuti... all'inizio il dvd con la iso non veniva visto... ho riavviato e tutto è partito bene.

mai avuto un freeze con il mio c300, in 40 giorni

[dj_andrea]

confermo i problemi del vertex 3 (dopo 2 giorni 3 crash) e il bios all'avvio non lo rilevava piu poi si .... e si è rallentato molto , per fortuna lo shop lo ritira e mi rimborsa pagando tutto . nel frattempo ho preso crucial m4 128gb mi pare sia ok quello vero?

[M4zinkaiser]

Davvero interessante queste "nuove" periferiche per la memorizzazione, mi sono affacciato solamente adesso al mondo dell'SSD e sembra una bomba per performance, anche se discretamente costosi >.>,

[WarDuck]

Originariamente inviato da M4zinkaiser

Davvero interessante queste "nuove" periferiche per la memorizzazione, mi sono affacciato solamente adesso al mondo dell'SSD e sembra una bomba per performance, anche se discretamente costosi >.>,

Beh considera che ad oggi con quella cifra non c'è nessun altro componente che ti dia una tale differenza di prestazioni, quindi secondo me il passaggio ad un SSD è da mettere al primo posto .

[JavaScript]

Originariamente inviato da TheDarkAngel

Se scrivi "zero" i controller sandforce scriveranno qualche manciata di dati

Quando scrivi in una cartella tramite sistema operativo i controller generalmente, per obbedire ai propri algoritmi di wear-leveling, scrivono i dati a caso e li mappano un po' dove par loro, quando però vai a leggere i settori fisicamente uno per uno la storia cambia, ho controllato personalmente (a campione) settore fisico per settore fisico un paio di SSD ed il risultato ottenuto è stato quello da me descritto, senza contare che scrivere degli "zero" dentro le celle significa solo scaricare un eventuale carica di elettroni in eccesso e non comporta cicli di scrittura addizionali per cui, al limite, male non fa, ma, salvo deprecabili e non ancora riscontrate eccezioni, il risultato deve esserci ed è controllabilisimo, ad esempio, con un banale editor esadecimale.

Provato su controller Toshiba di un TS128C Apple e su di un Mushkin Chronos Deluxe 240GB che monta un SandForce SF-2281 su ToggleNAND.

Originariamente inviato da Trotto@81

Il blocco fisico è di 4096 byte e la prima partizione deve iniziare da un multiplo di esso, mi fermo qui perchè sto andando a farmi un bel bagno a mare.

Questo lo dici tu perchè probabilmente "presumi" che il tuo SSD abbia tale dimensione di blocco oppure ne sei sicuro per qualche dato ben preciso in tuo possesso.

Ad esempio alcuni Intel usano blocchi da 8KB ovvero 8192 bytes così come recenti modelli montanti SF-2281 e generalmente hanno erase-block da 512KB ma tutto può variare in base al tipo di Flash utilizzata ed al layout di accoppiamento e controllo, ad esempio su un MKSSDCR240GB-DX che ho e che utilizza 16 moduli a doppio strato con 8MB per strato, 16GB per modulo, 256GB totali con 240 utilizzabili che diventano 223 formattati ed il solito 7% di spare ho notato un certo aumento della risposta utilizzando partizioni allineate sui blocchi FISICI, e con fisici intendo dire parizioni che inizino e finiscano sullo stesso modulo o su moduli contigui comunque utilizzati per intero, purtroppo non ho ancora altri dati che mi servirebbero per ottimizare il filesystem ma prima o poi ...

[TheDarkAngel]

Originariamente inviato da JavaScript

Quando scrivi in una cartella tramite sistema operativo i controller generalmente, per obbedire ai propri algoritmi di wear-leveling, scrivono i dati a caso e li mappano un po' dove par loro, quando però vai a leggere i settori fisicamente uno per uno la storia cambia, ho controllato personalmente (a campione) settore fisico per settore fisico un paio di SSD ed il risultato ottenuto è stato quello da me descritto, senza contare che scrivere degli "zero" dentro le celle significa solo scaricare un eventuale carica di elettroni in eccesso e non comporta cicli di scrittura addizionali per cui, al limite, male non fa, ma, salvo deprecabili e non ancora riscontrate eccezioni, il risultato deve esserci ed è controllabilisimo, ad esempio, con un banale editor esadecimale.

Provato su controller Toshiba di un TS128C Apple e su di un Mushkin Chronos Deluxe 240GB che monta un SandForce SF-2281 su ToggleNAND.

Non capisco come si possa bypassare il durawrite, non scriverà 5GB di zeri un sandforce e un editor esadecimale non può darti un riscontro diverso

[illidan2000]

Originariamente inviato da Portocala

Spendi quei 50 euro in più e prendi un M4 da 128GB.
Meno sbattimento di spazio in futuro e prestazioni superiori.

quoto. e dura anche di più perché non vai sempre a scrivere sulle stesse celle, poiché lo spazio è maggiore

[WJCasagrande]

Ciao a tutti...
Per la nuova Workstation, avevo scelto un vertex3 come disco di sistema ma, leggendo di tutti i problemi che sta dando, ho abbandonato l'idea.

Dovrei sostituirlo con un altro che sia, sopratutto, affidabile.

Nella stessa fascia di prezzo avrei trovato:

- SSD Crucial RealSSD M4 128GB 2.5" Sata3 CT128M4SSD2

- SSD Corsair Force F120 120GB 2.5" SATA2 CSSD-F120GB2-BRKT

- SSD Intel X25-V 320series 120GB 2.5" SATA2

Dovrei montarlo su una piattaforma AM3+ (sk.madre Gigabyte GA-990FXA-UD5 + AMD 1100T) e la mia preferenza sarebbe per il CRUCIAL
Voi esperti della materia cosa mi consigliate?

[JavaScript]

Originariamente inviato da TheDarkAngel

Non capisco come si possa bypassare il durawrite, non scriverà 5GB di zeri un sandforce e un editor esadecimale non può darti un riscontro diverso

Non è questione di bypassare il durawrite, la funzione "createnew" produce un file che nella bitmap di volume ntfs OCCUPA TUTTO LO SPAZIO disponibile che il controller accetta come "impegnato" e rimappa a modo suo, eraser è guidato dal sistema operativo e si basa proprio sulla bitmap di volume, sovrascrive il file in modo "grezzo" (raw) "riempiendolo" perciò di zeri allo stesso modo di come lo riempirebbe se si trattasse di "uno", punto. Tutto ciò provoca lo svuotamento di tutti i settori che vanno ad occupare quello spazio predeterminato lasciando peraltro libero il controller di stabilire dove allocarlo ma in ogni caso lasciando a fine scrittura tutti i file su disco e tutto lo spazio libero pieno di zeri....ovvero vuoto, scarico, rasato, in definitiva pronto per essere scritto al volo senza bisogno di ulteriori operazioni di riallocazione, in buona sostanza come appena uscito di fabbrica... ...e con il sistema installato ed operante ...

Provare per credere....

EDIT:

La stessa cosa la si può ottenere in linux mediante il comando:# dd if=/dev/zero of=/TRIM questo produrrà un file pieno di zeri (che all'atto pratico scaricherà tutte le celle che non siano utilizzate dal filesystem) fino ad esaurimento dello spazio libero.

Sono i due metodi migliori e che comportano la minor usura possibile delle celle in quanto write-amplification o meno un valore "zero" sequenziale e ad esaurimento dello spazio libero comporta solo un eventuale scarico delle celle parzialmente utilizzate e non certo un suo ricarico minimizzando in tal modo il consumo delle medesime, ti ricordo che la rimappatura di eventuali dati da spostare viene effettuata in memoria.


Ti faccio un esempio pratico: immaginiamo (per praticità) che un controller avesse la possibilità di leggere e scrivere il singolo byte, immaginiamo di avere cinque bytes di cui uno solo correttamente utilizzato dal file system, alti due vuoti ed altri due "incerti", ovvero da pulire in questo schema: (10110101) (00000000) (00001000) (00001000) (00000000) il filesystem sa che solo il primo bytes è valido e contiene dati da preservare, il controller NO, cosa succede, durante la garbage collection il controller tenderà a compattare i due bytes "incerti" ottenendo una cosa simile a (10110101) (00000000) (00000000) (10001000) (00000000) ma per fare questo sprecherà energie e riscriverà il byte ottenuto (in memoria) (10001000) da qualche altra parte liberando uno dei due byte (00001000) e conservando il byte inutile (10001000) da qualche parte, facendo come dico invece si ottiene un pattern di questo tipo (10110101) (00000000) (00000000) (00000000) (00000000) ovvero solo il byte effettivamente utilizato rimane scritto e tutto il resto dello spazio torna libero e pronto per essere riscritto subito senza bisogno di dover riallocare dello spazio, questo perchè i due bytes fasulli che andrebbero conservati nel normale processo di garbage-collection vengono imperativamente sovrascritti (o meglio "liberati") da una scrittura "raw" di zeri togliendo il problema al controller di dover conservare quei dati inutili che vengono in questo modo scaricati in quanto presnti nello spazio considerato "libero" dal sistema operativo che viene COMPLETAMENTE sovrascritto (in teoria) o meglio "liberato" (in pratica).

Se conoscete un metodo migliore per "ripulire" un SSD senza torturarlo fatemelo sapere.

[Macco26]

Originariamente inviato da JavaScript

Non è questione di bypassare il durawrite, la funzione "createnew" produce un file che nella bitmap di volume ntfs OCCUPA TUTTO LO SPAZIO disponibile che il controller accetta come "impegnato" e rimappa a modo suo, eraser è guidato dal sistema operativo e si basa proprio sulla bitmap di volume, sovrascrive il file in modo "grezzo" (raw) "riempiendolo" perciò di zeri allo stesso modo di come lo riempirebbe se si trattasse di "uno", punto. Tutto ciò provoca lo svuotamento di tutti i settori che vanno ad occupare quello spazio predeterminato lasciando peraltro libero il controller di stabilire dove allocarlo ma in ogni caso lasciando a fine scrittura tutti i file su disco e tutto lo spazio libero pieno di zeri....ovvero vuoto, scarico, rasato, in definitiva pronto per essere scritto al volo senza bisogno di ulteriori operazioni di riallocazione, in buona sostanza come appena uscito di fabbrica... ...e con il sistema installato ed operante ...

Non nascondo che la tua teoria è affascinante.. e tu mi sembri piuttosto preparato in materia e non lo nascondi.. Però dal mio piccolo ho ancora tutta una serie di dubbi, specie per i SandForce.
E' risaputo che i Sandforce usino la compressione e la AES encryption. Dunque qualsiasi programma, pur di basso livello, dovrà essere "traslato" dal controller per poter vedere l'output dell'encryption. Tu puoi credere che il tuo file sia 5 GB e pieno di zeri, però magari, con l'encryption, quello è qualcos'altro. 0 non è per forza zero nei Sandforce. Anche nell'ipotesi che il tuo Eraser passasse una cella alla volta da azzerare, ingannando il controller (che non riesce ad accorparle con 5GB in fila di zeri sì da comprimerli in qualcosa di più piccolo) l'encryption "ti fregherebbe". Per quella sessione di Secure Erase c'è una chiave crittografica che scriverà quei byte in un certo modo. Sicuramente NON 0. Ad un altra unità con chiave diversa, quel medesimo file verrebbe scritto in un altro modo ancora (sennò che encrypting sarebbe se tutto fosse uguale per ciascun disco)?
Per cambiare chiave, basta fare un Secure Erase. Il comando fa sì che il controller getti la chiave preesistente e ne generi un'altra.
La tua teoria di Erase parziale purtroppo non può fare questo (diverrebbe illeggibile la parte di spazio occupato dal SO).
Dunque tutti i crismi di un Secure Erase per SandForce (ripristino velocità max etc.) nel tuo caso.. non sarebbe possibile.
Idem accade con l'Intel 320, che, se non erro, usa AES anche lui per le sue celle.


Forse sugli altri SSD più "normali"..

[illidan2000]

Originariamente inviato da JavaScript

Non è questione di bypassare il durawrite, la funzione "createnew" produce un file che nella bitmap di volume ntfs OCCUPA TUTTO LO SPAZIO disponibile che il controller accetta come "impegnato" e rimappa a modo suo, eraser è guidato dal sistema operativo e si basa proprio sulla bitmap di volume, sovrascrive il file in modo "grezzo" (raw) "riempiendolo" perciò di zeri allo stesso modo di come lo riempirebbe se si trattasse di "uno", punto. Tutto ciò provoca lo svuotamento di tutti i settori che vanno ad occupare quello spazio predeterminato lasciando peraltro libero il controller di stabilire dove allocarlo ma in ogni caso lasciando a fine scrittura tutti i file su disco e tutto lo spazio libero pieno di zeri....ovvero vuoto, scarico, rasato, in definitiva pronto per essere scritto al volo senza bisogno di ulteriori operazioni di riallocazione, in buona sostanza come appena uscito di fabbrica... ...e con il sistema installato ed operante ...

Provare per credere....

forse mi sono perso qualche post. ma che sarebbe questo eraser ?

[Trotto@81]

Originariamente inviato da JavaScript

Questo lo dici tu perchè probabilmente "presumi" che il tuo SSD abbia tale dimensione di blocco oppure ne sei sicuro per qualche dato ben preciso in tuo possesso.

Non lo dico io, lo dicono i costruttori e sappi che anche gli hdd meccanici iniziano ad avere la dimensione dei blocchi pari a 4096 byte, non esistono dimensioni diverse, attento perchè stai facendo una gran confusione.

[dj_andrea]

Originariamente inviato da WJCasagrande

Ciao a tutti...
Per la nuova Workstation, avevo scelto un vertex3 come disco di sistema ma, leggendo di tutti i problemi che sta dando, ho abbandonato l'idea.

Dovrei sostituirlo con un altro che sia, sopratutto, affidabile.

Nella stessa fascia di prezzo avrei trovato:

- SSD Crucial RealSSD M4 128GB 2.5" Sata3 CT128M4SSD2

- SSD Corsair Force F120 120GB 2.5" SATA2 CSSD-F120GB2-BRKT

- SSD Intel X25-V 320series 120GB 2.5" SATA2

Dovrei montarlo su una piattaforma AM3+ (sk.madre Gigabyte GA-990FXA-UD5 + AMD 1100T) e la mia preferenza sarebbe per il CRUCIAL
Voi esperti della materia cosa mi consigliate?

io direi il crucial anche il corsair ha problemi (è sempre basato su sandforce come i vari ocz )

[JavaScript]

Originariamente inviato da Macco26

Non nascondo che la tua teoria è affascinante.. e tu mi sembri piuttosto preparato in materia e non lo nascondi.. Però dal mio piccolo ho ancora tutta una serie di dubbi, specie per i SandForce.
E' risaputo che i Sandforce usino la compressione e la AES encryption. Dunque qualsiasi programma, pur di basso livello, dovrà essere "traslato" dal controller per poter vedere l'output dell'encryption. Tu puoi credere che il tuo file sia 5 GB e pieno di zeri, però magari, con l'encryption, quello è qualcos'altro. 0 non è per forza zero nei Sandforce. Anche nell'ipotesi che il tuo Eraser passasse una cella alla volta da azzerare, ingannando il controller (che non riesce ad accorparle con 5GB in fila di zeri sì da comprimerli in qualcosa di più piccolo) l'encryption "ti fregherebbe". Per quella sessione di Secure Erase c'è una chiave crittografica che scriverà quei byte in un certo modo. Sicuramente NON 0. Ad un altra unità con chiave diversa, quel medesimo file verrebbe scritto in un altro modo ancora (sennò che encrypting sarebbe se tutto fosse uguale per ciascun disco)?
Per cambiare chiave, basta fare un Secure Erase. Il comando fa sì che il controller getti la chiave preesistente e ne generi un'altra.
La tua teoria di Erase parziale purtroppo non può fare questo (diverrebbe illeggibile la parte di spazio occupato dal SO).
Dunque tutti i crismi di un Secure Erase per SandForce (ripristino velocità max etc.) nel tuo caso.. non sarebbe possibile.
Idem accade con l'Intel 320, che, se non erro, usa AES anche lui per le sue celle.


Forse sugli altri SSD più "normali"..

Che io sappia la crittografia AES è abilitata di default solo su alcuni modelli, ad esempio alcuni Intel "business" level, altrimenti non è abilitata e nella maggior parte dei casi neanche supportata, in questo caso non stiamo parlando però di una scrittura logica, tutto quello che un controller può fare in questo caso è crittografare al limite il nome del file ma a noi non ce ne frega niente perchè lo stiamo andando a riempire in modo "grezzo" di zeri e con modo "grezzo" intendo una scrittura bit per bit sequenziale, zero dopo zero in modo "fisico", non "logico".. il sistema operativo "impone" di sovrascrivere un file composto da xxxxxxxx bytes con altrettanti bytes tutti aventi valore zero con dimensione assegnata, in pratica è come sovrascrivere un file incomprimibile con un pattern assegnato fisso, il controller non viene lasciato libero di esprimersi in ghirigori, obbedisce e basta, ovviamente il filesystem deve essere impostato per non consentire crittografia, altrimenti il controller potrebbe avere qualche chances di esprimersi.

Il secure erase non fa altro che scaricare tutte le celle contemporaneamente alla massima velocità concessa dai circuiti che permetta di non surriscaldare i bridges interni, in questo caso non si altro che fare la stessa cosa ma preservando i file presenti sul sistema che possono benissimo peraltro essere anche critografati, di questo non ce ne frega nulla, ripeto, è un'operazione "fisica" quella che si va ad effettuare, l'unica logica che c'è dietro è la gestione dello spazio ma questo, in definitiva, è limitato al valore massimo utilizzabile, un controller anche con le più aggreesive velleità crittografiche non può esimersi dal riempire lo spazio nel modo in cui gli è stato ordinato se questo avviene in modo fisico e non può neanche sovrascrivere lo spazio che già ha mappato come in uso.

Poi, se qualcuno vuole fare degli esperimenti per carità, liberissimo di farli, io li ho già fatti ed il risultato l'ho visto checchè ne dicano le varie teorie

Originariamente inviato da illidan2000

forse mi sono perso qualche post. ma che sarebbe questo eraser ?

E' un programma originariamente sviluppato per "sanificare" (rasare, cancellare, epurare) tanto dati quanto spazio libero sugli HDD, la versione corrente 6.0.8 non consente la creazione di pattern personalizzati mentre quelle precedenti si, consiglio la 5.8.8 perchè è l'ultima ad avere questa utilissima (nel nostro caso indispensabile) funzione.

Nel caso preso in considerazione prende il file, lo blocca e lo riempie di zeri senza chiedere altro in I/O diretto, il controller di un SSD a quanto ho provato passa il flusso direttamente alle celle scrivendole in modo grezzo, non ho fatto la prova con SSD che implementino di default la crittografia dei dati ma, anche in quel caso penso che la probabilità che la sovrascrittura raw avvenga sia alta.