Allineare SSD

[carlo2002]

Per allineare un SSD ho trovato molte guide con soluzioni più o meno complesse. però ho fatto caso che in Gparted c'è la possibilità di allineare la partizione, come si vede nell'immagine allegata c'è la scritta "Allineare a:", nella relativa tendina le opzioni sono:

- Cilindro
- MiB
- Niente

Quindi potrebbe essere una soluzione anche facile, qualcuno ha già provato?

Eventualmente quale opzione dovrei usare? "Cilindro" o "MiB"?

[franzauker2.0]

Direi che non c'entrano nè l'una nè l'altra.

[carlo2002]

Originariamente inviato da franzauker2.0
Direi che non c'entrano nè l'una nè l'altra.

Ossia ?

[denis76]

Scusa ma esattamente di cosa stai parlando?

[hfish]

non so se c'è qualche tecnicismo particolare dietro, ma di sicuro allineare al cilindro NON ha senso, visto che la visione logica dei dati su una SSD non è quella di traccia/cilindro

[MItaly]

Da quello che sentivo raccomandare l'allineamento "corretto" è a 1 MiB; lo screenshot che hai postato dovrebbe essere corretto.

[franzauker2.0]

La versione breve per gli SSD (esiste qualcosa di analogo per AF 512e, ma lo escluderei il doppio problema con l'SSD) è il meccanismo di scrittura che implica la cancellazione prima del "deposito" dei dati.
Se le strutture del filesystem sono allineate alla dimensione della pagina SSD (ed in verità anche al block size) allora la scrittura di un settore non causerà la cancellazione (nel caso peggiore) di DUE pagine SSD (aumenta il livello di tear)

Come si fa? Bhè è abbastanza difficile farlo bene, per non dire pressochè impossibile, se non si conoscono i due dati basilari (come detto pagina ed erase block size), che sono dati che fornisce (talvolta) il produttore degli SSD.
Comunque se supponiamo (ipotesi ragionevole) che valgano rispettivamente 4KB e 512KB, allora l'offset delle partizioni dall'inizio del disco deve essere un multiplo intero di 512KB (in realtà in questo caso perchè 512KB è già multiplo di 4KB)
- si aggiungerebbe anche che l'offset sia un multiplo intero della dimensione del cluster, ma questo è sostanzialmente sempre vero per gli ssd moderni che sono relativamente piccoli -

Immagino ci saranno 6 milioni di guide... non vorrei risultare troppo saccente

[MItaly]

Originariamente inviato da franzauker2.0
Immagino ci saranno 6 milioni di guide... non vorrei risultare troppo saccente

In realtà ci sono 6 milioni di guide, ma è difficile trovarne una che spieghi decentemente e in sintesi il problema (si perdono tutte sull'uso di questo o quel tool di partizionamento); ergo, grazie per il post.

[franzauker2.0]

Visto che, sorprendentemente, l'argomento sembra interessare, preciso un minimo quanto scritto sopra.
Ovvero che la memorizzazione degli SSD avviene su 3 livelli, pagina, blocco e un "di più" che cambia nome a seconda del produttore.
Una pagina sono tipicamente 4K (per inciso ci sono un sacco di studi su dimensione pagina, paginazione dei sistemi operativi ed anche prestazioni degli RDBMS, ad esempio mysql-innodb utilizza pagine da 16K e qui si aprirebbe un mondo... chiuso inciso), ma questo in realtà non è l'unità minima che possa essere scritta, che è il blocco.
Questo (detto anche NAND erase block, supponendo che si utilizzino questo tipo di memorie, cosa a sua volta non scontata come sta dimostrando samsung blablabla fine inciso) è tipicamente di 512KB.
Il "di più" è normalmente 512MB (qui dipende dal controller e si aprirebbe tutto il discorso sui vari tipi di controller SSD fine inciso), ma non ci interessa particolarmente in questo caso visto che ha riflessi sull'IOP piuttosto che sul degrado.
Credo ormai sia chiaro che se voglio cambiare un bit devo leggere un intero blocco da 512KB, cambiare il bit, riscriverlo.
Ecco la giustificazione sull'allineamento a tale dimensione per far sì non vi sia overlap tra le strutture del file system e quelle fisiche dell'SSD.

A dir la verità questo era vero, oggi non lo è più tanto, a cagione delle nuove tecnologie per memorizzare le informazioni (ovviamente a costi più bassi) che tendono a far somigliare gli SSD a... chiavettone, ovvero TLC invece di MLC (o MLCe o SLC)

[franzauker2.0]

Azz mi son reso conto che magari non è così nota la differenza tra le varie tecnologie (ammesso che interessi a qualcuno, chissà).
Ad ogni modo, evitando come al solito le saccenze, le celle NAND sono essenzialmente sempre le stesse (costituite da transistor molto simili)
Sostanzialmente SLC memorizza un bit per ogni cella, MLC ne tiene due, questo fa sì che una superficie di tot celle diventano tot byte/8 SLC e 2x MLC (in realtà no, perchè c'è lo spazio dovuto alla correzione degli errori e le celle vuote per la rilocazione etc. facciamo finta di saperlo).

Il risultato netto è che MLC "rende" il doppio di SLC, ciò si ottiene attraverso la "solita" tecnica (usata anche analogamente ma in frequenza e non in tensione, per le ADSL "primissimo stampo") di multiplex degli stati.

Bene, TLC (T sta per triple, penso sia chiaro) memorizza 3 bit per ogni cella, il che fa sì che i produttori, banalmente, lascino inusati una parte del die per avere la medesima dimensione per l'utente.
In altre parole shrinkano la dimensione fisica dei chip, sicchè a parità di spazio-utente ne fanno stare (circa) 1/3 in più per wafer = riduzione dei costi del 30% circa.

Questo però ha un costo, sia come cicli di lettura-scrittura (che sono per TLC circa 1/100 di SLC), sia come velocità, che è circa 3 volte più lenta per TLC rispetto a SLC e +50% rispetto a MLC.
Il vero "dramma" sono le tensioni da applicare, notevolmente maggiori rispetto a SLC (hanno 8 livelli anzichè 2), ed ogni applicazione fa un mini "buchino" nel substrato della cella.

Cosa c'entra tutto questo? C'entra, perchè i pochi coraggiosi che stanno intraprendendo la strada TLC (per quanto ne so solo Samsung è in produzione col modello 840) devono combattere con una "resistenza" bassissima all'usura, e quindi adottano - via firmware - strategie segrete (o per lo meno ad oggi segrete) per ridurre il problema della scrittura a blocchi.

Come? Non si sa, o almeno io non lo so, si specula su erase block size molto più piccoli.

Sarà vero? Boh.