Presne tak, u starsich SCSI disku lze menit velikost sektoru po reformatovani.
A ten problem s malym vykonem „kvazi 4K“ disku maji na krku jejich vyrobci, protoze tyto disky se v systemu jevi porad jako 512-byte sektorove – a pokud udelate takovy zapis, je samozrejme ze 4K sektor se musi precist, pak nasleduje kompletni otacka plotena pak se zapise novy 4K sektor..
A tento samy problem problem je u SSD.. jez maji vnitrni „sektory“ jeste vetsi..
Pokud by vyrobce disku nabidl nativni 4K disk (ktery na svem rozhrani prenasi 4K sektory), tak by bylo vse v poradku, na to je Linux pripraven.
Aspon je videt co stoji zpetna kompatibilita.. 300% … a ted to aplikujte na svet x86 nebo Windows .. jaky vykon by se dosahl bez podminky zpetne kompatibility :)
Pokud je situace, jaka je, tj. vyrobce emuluje 512B sektory, proc by na to mel byt linux nepripraven? Ja na svem disku SSD mam nastaveny zacatek vsech oddilu na nasobky 512kB (neni zadny problem to nastavit) a pri vytvareni fs jsem nastavil, ze ma zarovnavat na 128kB. Predpokladam, ze totez lze nastavit pro 4k sektorovy disk. Tak jaka nepripravenost? Linux by byl nepripraveny, kdyby to neslo udelat.
Mozna nejsou pripraveni linuxovi uzivatele, ale who cares? Novy disk je potreba nekdy rozdelit a skoro vzdy naformatovat. To muzu udelat dobre a nebo spatne, v druhem pripade se pak nesmim divit.
Btw, dokazal bych si predstavit, ze by vyrobce jako pridanou hodnotu disk predrozdelil a predformatoval na NTFS pro windowsare se spravnym nastavenim, aby onen 300% propad nemel.
Ja vidim v diskovych polich na SCSI 2 druhy adresovani, co se tyce vetsich volumu nez 2TB
a to:
4k … max 16TB
a LBA64 … v radech petabyte.
Linux podporuje oboje ;-)) … ale doporucuje se LBA64 … kazdopadne, s LBA64 maji problem windows, velmi casto jej nepodporuji.
Jinak na linuxu nepodporuje tyto disky fdisk, je treba udelat GPT label misto msdos pomoci gpart ;-))
Na zapis 512B sa musi precitat 4KB velky blok, zmenit v nom konkretnu cast a zapisat 4K na disk. Teda najhorsi pripad je, ze namiesto jedneho zapisu urobis 8* vetsie citanie a 8*vetsi zapis, teda 1600% spomalenie. To by nastalo pri hmmm, „buterfly write“ rezime – male zapisy po rozlicnych miestach disku. Pri sekvencnom zapise verim, ze disky nemaju svoju 32MB+ cache na srandu kralikov a pouziju ju – pockaju na 4K dat v jednom kuse a nemusia sa trapit.
V priemere tak raz stratis az 16*, inokedy zasa usetris (pri sekvencnom citani a zapise). Priemer v ich testoch bol 300% strata…
A samozrejme zabudam na otacanie disku – nastavenie hlaviciek trva dost dlho, ale pri oboch typoch (male aj velke bloky) trva rovnako. Ale aspon pri SSD by to mohlo platit.
Ztráta výkonu nikdy nemůže být více než 100%. A i těch 100% znamená, že to přestalo fungovat. Jde o slovo „výkon“ (práce za jednotku času). Pokud teď dokážete zpracovat 10MB za sekundu a s novým diskem jen 1MB za sekundu, ztratil jste 90% výkonu. Pokud nedokážete zapsat nic, pak jste ztratil celých 100% výkonu.
Jinými slovy: pokud to trvá třikrát déle, tak toho za jednotku času zvládnu zapsat jen třetinu. To znamená, že výkon klesl na třetinu, tedy klesl o cca 67%.
Pokud ani teď někomu není jasné, proč autor budí dojem, že nedošel ani do 7. třídy ZŠ, zkuste si experiment. Dejte si na stůl několik mincí. A nyní jich zkuste 300% ztratit.
Zrovna jsem dostal WD15EARS výměnou za reklamovaný disk WD15EADS, takže jsem si s tím trochu pohrál. Problém je, že výrobce WD reportuje navenej, že disk má fyzickou velikost sektoru (stejně jako logickou) 512B. IMO je tohle bug firmware a je to zralé na opravu. Pokud si uděláte korektní alignment oddílů (zarovnaný na 4KB), žádná ztráta výkonu se nekoná. Musíte se o to postarat ovšem sami.
Více viz
http://community.wdc.com/t5/Desktop/Problem-with-WD-Advanced-Format-drive-in-LINUX-WD15EARS/td-p/6395