Linux není připraven na disky s 4K sektory

Pokial viem, tak velkost sektora sa da menit na (niektorych?) SCSI diskoch – aj peknych par rokov starych. Preto je dost divne, ze to nikto neriesil.

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 :)

mam ten pocit ze tie disky to rozhranie maju, len sa spusta 512B emulacia pre starsie OS.. Win7 to myslim dokaze vyuzit

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 ;-))

Jak může být ztráta 300%?
30% chápu, místo 100MB dat za stejný čas zpracuje jen 70MB ale 300%? To by vyšlo –200MB to mě hlava nebere, může mi to někdo vysvětlit?

Na 100 MB bude 300 MB balastu. To znamená že aby jste si uložil svých 100 MB budete potřebovat 400MB prostoru. (Pokud to dobře chápu. :))

Takže to není ztráta výkonu ale o 300% „víc práce“ takže ztráta výkonu je 75%.

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.