Newsgroup: it.comp.hardware.storage
Titolo: Due articoli sulla formattazione avanzata 4K

Sia su HotHardware che su Tom's Hardware sono stati
presentati due articoli sulla formattazione avanzata
(4KB per settore) inizialmente introdotta da Western Digital
sui dischi Caviar Green (mod.WD-EARS) e successivamente
anche su altri modelli.
HotHardware:
Exploring WD's Advanced Format HD Technology
(26/02/2010)
http://hothardware.com/Articles/WDs-1TB-Caviar-Green-w-Advanced-Format-Windows-XP-Users-Pay-Attention/
Tom's Hardware:
"HDDs, The Next Generation: Drives With 4KB Sectors On The Way"
(26/02/2010)
http://www.tomshardware.com/reviews/wd-4k-sector,2554.html
In particolare su HotHardware si analizzano le prestazioni
con Windows XP che non supporta l'AF e si scopre che
le prestazioni sono molto penalizzate a causa dell'emulazione.
Si sfata anche il mito della maggior capacit� dovuta all'AF:
aumenta lo spazio fisico disponibile sul disco ma sta alle case
produttrici allocarlo o meno, cosa che evidentemente in
WD non hanno ancora fatto.
Ciao
Luca

 Luca
Insomma al momento ï¿œ una "chiavica"...:DDD

> 
http://hothardware.com/Articles/WDs-1TB-Caviar-Green-w-Advanced-Format-Windows-XP-Users-Pay-Attention/
Mhh... "1 byte = 10 bits" ...  "8 x 40 bit = 320 bytes"...  non sono sicuro 
di volermi fidare  :D
Pleg

Il 02/03/10, Pleg ha detto :

LOL... meno male che non ho letto l'articolo allora :D

 LOL... meno male che non ho letto l'articolo allora :D
stai tranquillo ;)
la spiegazione � fatta abbastanza bene e chiarisce alcuni dubbi
avuti da molti, dopo aver letto l' articolo di anandtech
( 
http://anandtech.com/storage/showdoc.aspx?i=3691
 )
purtroppo hanno scritto male e siccome non hanno nessuno
che gli corregge gli errori non hanno ancora fatto l'errata corrige :P
formattazione attuale:
in ogni settore di 512Byte ci sono 40Byte di ECC
quindi per un cluster di 4KByte ci sono 320Byte di ECC
nella formattazione avanzata:
in un settore di 4KByte ci sono 100Byte di ECC
con un risparmio di 220Byte per ogni cluster di 4KByte
questo non significa che se vendono un disco da 1TB con AF
ci puoi mettere pi� dati, altrimenti l'avrebbero venduto da ~1,1TB
ma che in futuro potranno farlo (o perlomeno potrebbero)
in alternativa, a parit� di capacit�, potrebbero discriminare la parte
interna del disco ed aumentare il transfer/rate medio ed il
tempo d'accesso medio
sono piccole variazioni ma, aggiunte al miglioramento del controllo
degli errori, sono ben accette
luca

 che gli corregge gli errori non hanno ancora fatto l'errata corrige :P
Mi offrirï¿œ io allora...LOL
Comuqnue si... diciamo che se non altro la "nuova" formattazione 
permette in teoria di migliorare l'integritï¿œ dei dati oppure le 
prestazioni (piï¿œ che altro in via strumentale comunque).

Lorenz ha spiegato il 02/03/10 :

Anzi no... al limite "migliorano" solo le prestazioni, dato che i dati 
destinati all'ECC diminuiscono.

 destinati all'ECC diminuiscono.
non l'ho capito bene ma in effetti il controllo ECC dovrebbe migliorare
(migliora il Max Burst Correction)
se i 40Bytes di ECC per 512B non sono pi� sufficienti a causa del
S/N dovuto all'aumento della densit� di registrazione, la soluzione
sarebbe quella di aumentarli a 80Byte passando da 400bit ad 800bit
di Max Burst Correction, con peggioramento della efficienza di
formattazione scendendo dall'attuale 87% all'81%
ma secondo studi, basterebbero 100Bytes ogni 4KBytes ed
� questo il motivo dell'introduzione della  nuova AF-4K che
aumenterebbe il Max Burst Correction a 1000bit con una
efficienza di formattazione del 96%
se c'� qualcuno che ne sa di pi� o vuole approfondire scendendo
nei dettagli � invitato a partecipare alla discussione
ciao
luca


Se diminuisci di tre volte lo spazio ECC per cluster non vedo come 
possa migliorare l'integritï¿œ dei dati anche aumentando il max boost 
correction, al limite alla fine hai gli stessi livelli di 
sicurezza...inoltre non si capisce che fine abbia fatto il cosiddetto 
"preambolo", ovvero lo spazio destinato al controllo che
permette alla testina di "sincronizzarsi" prima di leggere o scrivere 
informazioni nel disco, importante pure quello.
Insomma... "l'ambaradan" ancora non ï¿œ che mi convinca molto :D
Vedremo gli sviluppi futuri della faccenda...

 correction
Basta usare codici diversi. Con 4 kiB invece di 512 B hai piu'
"spazio" su cui lavorare, inoltre puoi usare codici piu' potenti e
sofisticati (grazie anche
al fatto che oggi abbiamo abbastanza potenza di calcolo per
implementare codici molto sofisticati in aree accettabili). Nel
complesso, non mi stupisce.
Il fatto e' che 220 Byte risparmiati su 4 kiB sono appena un 5%, il
guadagno in termini di spazio non sembra essere molto. Magari si
guadagna di piu' dalle
zone di guardia che si risparmiano... ma non so molto del layout
fisico dei dischi.
Pleg

fisico dei dischi.
si risparmiano Byte diminuendo anche  il numero di blocchi di preamble
in pari misura al numero di blocchi ECC
la stima � del  7-11% (fonte WD)
chiss�, forse si pareggiano i conti, finalmente, tra i "giga" e "gibi" ;)
luca
ps: siccome appartengo alla vecchia generazione dei "kappa" e
dei "mega", faccio molta fatica con "kibibit", "kibibyte" ecc
gi� le maiuscole e le minuscole sono un problema, aggiungere
anche una "i" non mi viene ancora naturale ;)
forse sarebbe il caso di scrivere un bel post a riguardo ...

 Vedremo gli sviluppi futuri della faccenda...
credo che per gli utenti finali sia tutto trasparente ma al potere
del marketing non c'� limite ;)
ciao
luca


Appunto... :/