Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Zrovna tady mi přijde divný, proč by se o to měl starat OS (respektive ovladač), když všecko nejlíp o disku ví řadič disku, čili firmware. FW by přece měl být udělán tak, "aby si to všecho zařídil a ohlídal".
Vždyť proč se přešlo z CHS na LBA, aby se OS nemusel starat o to, jak je to fyzicky na tom disku. Stejně tak NCQ - řadiči chci tyhle bloky, přečti si je jak chceš, vrať mi je klidně přeházené, hlavně když to bude rychle.
FW si umí zajistit, aby data byla zapsaná správně, ale těžko může něco zařizovat. Není to SSD, které přemapovává bloky podle svých potřeb. Také si SMR disk moc nemá kam sypaná data data odložit, takže musí zapisovat co to dá a jinak žádat přerušení. Cache má jen omezené možnosti pojmou data před jejich "magnetickým zapracováním".
Pokud filesystém ví jaká jsou omezení disku (které stopy nelze zapsat přímo, aniž by se přepsaly sousední), tak nebude data do bitmapy posílat v nevhodném pořadí (proti srsti šindelí), disk tak bude reagovat svižněji, protože méně bude narážet na omezení daná technologií.
Prostě se to disku posílá tak, aby to pro něj bylo co nejméně pracné či zdlouhavé zapsat. O šindele se stále musí postarat sám.
„Také si SMR disk moc nemá kam sypaná data data odložit...“
Věřte tomu, že má ;). Dělám teď na téma SMR jednu recenzi a ten disk mě nepřestává překvapovat. Už to snad začnu finišovat, měl jsem i zajímavý rozhovor s PR oddělením výrobce.
A ten FW na to jde cestou nejmenšího odporu, tudíž dost blbě. Tohle je fakt imho lepší nechat na systému.
Jsem zvědav, kdy budou SMR disky podporovat Windows.
Má si kam odložit? Tak to mě docela zajímá. :-)
Taky mě to překvapilo :)
Ono logických možností příliž není.
a. DRAM: načíst soubor stop, přeorganizovat a zapsat zpět. A co když vypadne napájení ? Disk nemá ponětí o tom jestli filesystem podporuje transakce a jestlí ví, že je SMR. Tudy cesta zřejmě nevede.
b. flash cache: proč ne, ale zřejmě není na trhu model, co by přežil dostatečně dlouho.
c. dedikované místo na disku, může být SMR, nebo ještě lépe PMR. Data nejdříve zduplikuje (pokud již duplikát neexistuje). Zapsat zpět je může až bude mít čas. Proč by toto místo nemohlo být desítky GB velké. Taková místa by mohly být dokonce rozeseta po celé plotně, tak aby minimalizovaly pohyb hlaviček.
e. anebo se uplne vykasle na krasnou strukturu a proste remapuje logicke bloky, nicmene by zrejme musel disk vedet, ktere jsou prazdne. Ze by podobnost s TRIM u SSD. Jenze oproti SSD je zde rozdil, ze ruzna mista na disku maji ruznou rychlost a hlavne ruznou pristupovou dobu.
Na desktopu nas to stejne nemusi trapit a pevne doufam, ze ani nikdy nebude.
Na desktopu nas to stejne nemusi trapit a pevne doufam, ze ani nikdy nebude.
No, mě to trápí. Jen nevěřícně kroutím hlavou a koukám, jak přibývají technologie, které bych si radši v žádném výrobku nikdy nekoupil. Bohužel za nějakou dobu nebudu mít na výběr. Ba se ani nedozvím, co do té černé krabičky, kterou si jednou koupím, všechno nastrkají. Dnešní moderní trendy se mi ani trochu nelíbí.
To s moderností nemá nic společného. Blížíme se různým technologickým limitům a dokud se nenajde jiná cesta, nezbyde než ze současných možností vyžmuňkat maximum.
Já bych si ale nestěžoval. Třeba nikdy předtím jsem doma neměl možnost mít několikanásobně prozálohováno na rychlých HDD, jen vypálit zálohy fotek byly hodiny práce s vypalovačkou. Systém zálohuju jako image, místa všude spousty. Vždycky před tím to byl zápas.
"FW si umí zajistit, aby data byla zapsaná správně, ale těžko může něco zařizovat" - tady si právě myslím, že FW by si to MĚL zařídit. Je to stejné jako u toho NCQ, dokud je ve frontě 1 požadavek, NCQ se neuplatní. Jak jich tam OS nasype víc, řadič disku je zpracuje v pořadí, jak uzná za vhodné.
Tady u SMR pokud bude ve frontě 1 požadavek, tak se taky nic neděje. Když jich tam OS nasype víc, čekal bych, že FW si z nich vybere a zařídí si to tak, aby to bylo "dobře".
Je možné, že současný stav je takový, že FW je "hloupý" (jak psal Wift) a až přijde "SMR 2.0", bude FW dělat to, co dnes dělá OS.
Vždyť jaký je dnes rozdíl mezi WD disky Green/Purple/Red/Gold - po HW se moc neliší, liší se hlavně tím, jak zpracovávají požadavky, takže FW.
No já mám pocit, že jste nepochopil co to SMR disky jsou. To je opravdu diametrální principiální rozdíl oproti klasickému HDD, není to jako něco mezi barvičkama WD klasických disků, kde se odlišuje "jen" dimenzování mechaniky, různé nakládání s chybami ve FW atp.
Jde o to (zjednodušeně), že zapíšete stopu 1, OK. Zapíšete stopu 2, čímž se částečně přepíše stopa 1, do stopy 1 už tedy nejde libovolně zapisovat. Pokud tam systém něco zapsat chce, disk musí opravit i ty existující překrývající stopy. Pokud OS posílá data nevhodně, tak disk musí zbytečně "opravovat šindele", které přepsal tím, že zapsal do nižší stopy. Pokud OS tento princip zná, bude takové požadavky po disku vyžadovat co nejméně a sám si to vhodně uspořádá. Fungovat to bude, ale výkon disku při zápisu bude zoufale snížen.
Zároveň mechanický disk nemá takový výkon náhodného čtení, aby si mohl bloky libovolně přemapovat jako to dělá SSD. Tohle je opravdu o dost jiná situace než NCQ, které je prohazuje pořadí požadavků, aby s tím disk měl méně štrachání, ale na principu zápisu se nic nemění. Na SMR nelze zapisovat libovolně a tak zpřeházení požadavků většinou ničemu nepomůže.
Předpokládám, že u SMR právě nejvíce pomůže stavět bitmapu disku chytře, aby šly šindele vždycky pěkně na sebe a pokud možno nepoužívat bloky "nad", takže disk nebude mít zbytečnou práci s "flikováním" nevhodného postupu obsazování stop.
"pomůže stavět bitmapu disku"
Wut ? co je to "bitmapa disku" ? a kdo ji ma jakoze stavet ?
Staví ji filesystém. Je to mapa volných/obsazených bloků. Říká se tomu různě, Allocation Bitmap, Free space bitmap. Třeba na SD kartě nebo flešce (FAT) se vám při nevhodném vypnutí přístroje nebo vyjmutí může stát, že tam nebude jediný soubor a přesto nebude dostupná plná kapacita, kvůli nesouladu mezi obsahem FAT a bitmapou oddílu.
Jo, tak tohle pevný disky afaik nemaj. To by ten disk musel počítat s každým existujícím i budoucím filesystémem a to není v jeho moci. Ten popisovaný případ s SD kartou či fleškou se afaik týká obecně jakéhokoli disku s FAT (FATka byla na tohle fakt blbá).
1) bitmapa volneho mista filesystemu muze byt, nic jako "bitmapa disku" neexistuje ;) (navic ne vsechny filesystemy pouzivaji bitmapy)
2) bitmapy zabiraji pomerne malo prostoru, navic kazdy novejsi FS pouziva extenty, takze pochybuji ze zrovna todle by melo smysl optimalizovat pro SMR...
3) "kvůli nesouladu mezi obsahem FAT a bitmapou oddílu" << opet, nic jako "bitmapa oddilu" neexistuje, a FAT vubec nepouziva bitmapy. Muzete mit nesmysly ve FAT tabulce (a ty problemy co pisete), ale zadne bitmapy tam nejsou...
1) psal jsem to hodně zjednodušeně pro někoho, kdo zřejmě nemá úplně představu jak to funguje (ano vím, že ne všechny filesystémy bitmapu používají). Uznávám, že bitmapa disku je hodně zjednodušená, ale někdo kdo to nezná by si zase nemusel spojit, že bitmapa filesystému = "obraz" bloků daného oddílu na disku. Snaha být obrazně výstižný často naráží u těch co chtějí terminologickou přesnost.
2) Samozořemě nejde o těch pár kb či mb kde je bitmapa ve filesystému zapsaná. Jde o to, že filesystém to pere přímo na nějaké konkrétní adresy, které má (v bitmapě) poznačené jako volné. U SMR je záhodno brát v úvahu nejen volné bloky, ale též bloky jdoucí "po šindelové střeše shora dolů".
3) ad 1. U HFS+ na macu se tomu třeba říká "Volume bitmap", prostě se tomu říká různě. Máte pravdu, hodně teď používám ExFAT a ten alokační bitmapu používá, tak už mi to vytěsnilo zkušenosti s FAT16 a FAT32.
Jinak bitmapa se používá u ExFAT, NTFS, EXT2-4, HFS, BTFS také částečně, modernější filesystémy požívají výkonnější extent map a asi existují i další způsoby jak si zmapovat obsazenost bloků.
Je to jen nepatrně jinak: zapsání stopy N znehodnotí data na stopě N+1 (a kdoví, jestli ne i na N+2 - jak je fyzicky ta záznamová hlava velká, nevím). Fakticky se tak musí při změně jednoho sektoru zrekonstruovat celá sada stop až po stopu, za kterou není stopa žádná (je tam kus „hluchého“ místa, resp. je tato stopa širší), další stopy tím nejsou již dotčeny. Z toho vyplývá, že takovému disku nejvíce svědčí sekvenční zápisy. Vyloženě masakrózní je sada náhodných zápisů a pro mě bylo poměrně šokujícím zjištění, jak se v takovém případě disk zachová. Víc zatím neprozradím (aspoň budu mít motivaci ten článek dokončit ;).
Do recenze mi fakticky chybí zpracovat video, které pojednává o tom, jak se právě chová disk, který dostane čočku v podobě hromady malých náhodných zápisů.
Tak to se hodně těším.
Jestli něco tomuhle disku neudělá moc dobře bude asi pokus o klasickou defragmentaci, což? :-) Leda by dafragmenťák znal strukturu šindelení a nejdříve si místo pročistil pro následné skládání.
Právě od toho je ten Zone ATA Command, co se o něm píše v článku, aby OS znal strukturu šindelení a preferoval sekvenční zápisy. Musí to ale podporovat samotný disk a ne všechny to podporují (ten, co s ním mám tu čest já, to nepodporuje).
Já vám klidně prozradím, co SMR disk dělá s náhodnými zápisy
Drive managed SMR drives cope with these shortcomings by leveraging a “landing zone” of sorts, where random writes can be managed before being written to disk. The ways of incorporating this space on SMR drives can vary widely though, leading to significantly different performance profiles depending on the target market of each drive and manufacturer.
http://www.storagereview.com/methods_of_smr_data_management
SMR disk je v podstatě takové hroooozně pomalé SSD s velikostí bloku 1000x větší než mají flash paměti - 128 nebo 256 MB. Část disku se může chovat jako SLC cache u Samsungů EVO.
Takhle teoreticky je to sice jedna věc (a ještě trošku zjednodušeně), ale praxe je o poznání veselejší ;).
Mimochodem jsem zkoušel googlit, jak jsou na tom Windows s „podporou SMR disků“ - nic, co by mě navedlo k odpovědi, jsem nenašel. Mi to připadá, že Windows s tím zatím nepočítají (všechno kolem SMR se točí hlavně kolem Linuxu - tam se to asi odladí a pak si to MS obšlehne, nebo já nevím ;).
Peter Desnoyers si dal práci s tím, že vyříznul do SMR disku okýnko a natočil, jak vypadá náhodný zápis prakticky - prostě úplná nuda https://www.youtube.com/watch?v=NNKJaziktzE
https://www.usenix.org/conference/fast15/technical-sessions/presentation...
To by mě zajímalo, proč tam vyřezával okýnko. Proč prostě jen nesundal kryt :)
" stopy N znehodnotí data na stopě N+1 (a kdoví, jestli ne i na N+2"
To N (= band size) dle http://wp.xin.at/archives/2633 je mezi 5 az 10 stop.... dle jinych zdroju HGST pouzilo 256MB band size (ale buhvi kolik se vejde na skutecnou stopu MB, takze kdovi kolik je to stop)
Dle ^^ je u N = 2 je to zvyseni hustoty zapisu prilis male, aby se to vyplatilo.
Je otázka, jestli tahle technologie přežije dostatečně dlouho vzhledem k nástupu SSD. Možná v případě serverových disků, ale jak tady někdo v diskuzi už psal, budoucí enterprise disky budou jistě mít kvalitnější firmware a nebudou potřebovat, aby se o tohle staral kernel. A ve spotřebáku tahle technologie nejspíš skončí dřív než by se prosadila... Takže stojí za to nechat nabobtnávat kernel a tím zvyšovat riziko chyb?
Pochybuji že někdo bude zálohovat na SSD. Kapacita HDD ještě bude dlouho potřeba, zatím se alespoň nerýsuje žádná alternativní dostupná technologie. A magnetické disky jsou na hranici možností, takže s většími kapacitami nás asi šindele nějaký čas čekají, než někdo vynalzene něco vhodnějšího.
Prča je v tom, aspoň to tak zaznívá z odborných kruhů (výrobci a ti, co s nimi spolupracují), že šindelovat se bude i s novými technologiemi, takže třeba bude HAMR+SMR apod. (sice mi to technicky trochu hapruje, mám drobátko problém si to představit, ale tvrděj to ;).
Oni tu trvanlivost SSD a HDD srovnaji, toho bohda nebude aby si uzivatel mohl neco v klidu doma ulozit ...
Tak na tom, že nejspíše všechny budoucí enterprise disky budou šindelovat, se můžeme shodnout... já si ale myslím, že u běžného uživatele, u notebooků zvláště, se budou používat už jen SSD.
Na zálohování (filmy, muzika, dokumenty, fotky) pak stačí malý externí disk např. nějaký WD portable - nejsem si jist, jestli pro tyhle případy, kdy tam jako uživatel cpu sekvenčním zápisem pulgigové soubory atd., bude nějaké kernelem řízené šindelení představovat zásadní zrychlení.
Na WIFTůf clanek o SMR disku se tesim, ale zajimal by me spis seznam vsech disku ktery SMR vyuzivaji - aby jsme vedeli cemu se vyhnout :P.
Ne u vsech disku (modelů) to totiz na sebe vyrobce primo praskne, takze pokud chce clovek vyssi kapacity tak musi byt jeste vice obezretnejsi nez drive :(
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.