Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: xsouku04 02. 08. 2024, 23:54:31
-
NVMe disky často lžou o velikosti svých sektorů - nejmenší zapisovatelné oblasti. Hlásí 512 B i když ve skutečnosti nejmenší data, které mohou zapsat jsou 4 KB nebo dokonce 8 KB.
Dělají to prý z toho důvodu, aby mohli fungovat i na obstarožních operačních systémech,pro které by jiná velikost sektoru mohla být problém.
Nechápu ale pak, proč v těchto vylhaných jednotkách počítají i množství zapsaných dat, tedy životnost disku.
Percentage Used: 0%
Data Units Read: 779,217 [398 GB]
Data Units Written: 1,317,842 [674 GB]
To číslo 1317842 je počet 512B bloků v tisících 1317842*512*1000.0/1000/1000/1000= 674 GB
Snažím se přijít na to proč při použití ZFS hlásí disky až desetinásobně zápisů oproti tomu když stejná databáze běží na ext4. Jestli to není do velké míry jen chyba měření.
ZFS s ashift 12 a recordsize 4KB má nejmenší zapsatelný blok dat 4 KB, které musí zapsati při změně jednoho bytu.
Naproti tomu ext4 zapíše jen 512B a firmware disku si to musí vyřešit sám, takže stejně nakonec zapíše 4 nebo 8 KB. Ale jde o to jak to započítá do množství celkově zapsaných dat a životnosti disku.
Změna jednoho bytu znamená zápis 8 nebo 16 jednotek? Přišlo by mě to nejlogičtější. Pokud by to tak bylo, neměl by být problém detekovat skutečnou velikost sektoru, což ale problém je.
Totiž při použití ZFS pozoruji v smartctl řádově větší zápisy než při použití ext4. Takže i lepší disk se ZFS by při mém použití měl mít životnost jen několik let. Není to ale jen chyba měření?
Da discích běží databáze mysql s hodně zápisy a updaty. Také je mi divné, že podobný problém nikdo další nehlásí.
-
ZFS je CoW (copy on write), teda každý zápis i malinký do datbázového souboru udělá prostě jeho kopii. Což násobí počty zápisů oproti ext4.
CoW se na databáze nedoporučovalo a na BTRFS to jde i pro jednotlivé soubory/adresáře/globálně vypnout.
-
Neznám konkrétní SSD, nicméně:
OK, možná SSD reportují nepravdivou velikost bloku a navenek v tom počítají i další věci, nicméně nevidím úplně důvod, proč by to měly takto počítat i interně. Čekal bych, že interní počítadla budou počítat se skutečnou velikostí bloku, a následně pro report to vynásobí (což bude asi bitový posun). Nedává mi naopak smysl, aby to nezohledňovalo write application. (BTW, říkám si, že by mohlo být celkem snadné to otestovat pomocí dd. Ideálně ne přímo na FS, ale na nějaké partition (přímo pod GPT, ne pod LVM a ideálně ani dm-crypt), případně na celém SSD.)
O ZFS mám spíše hrubou představu, a nejspíš zde bude záviset i na nastavení, nicméně tuším několik důvodů, proč zde může být větší write amplification (byť desetinásobek překvapil):
1. Některá data si ZFS může prvně zapsat do ZFS intent log, a teprve potom je skutečně zapsat. (I když si nejsem jistý, jestli se to používá i na SSD.)
2. ZFS se může starat o integritu dat a zapisovat data nějakým více či méně transakčním způsobem, což může být další zdroj write amplification. Což bude asi ono CoW, co zde zmiňuje Jan Fikar. U databáze to dost možná bude nošení dříví do lesa…
-
SSDčka jsou zrádná, QLC ti v serveru chcípá před očima. TLCčka jdou, ale pokud to není serverový disk, nemůžeš použít celou jeho kapacitu, ale vyhradit tak maximálně 80% a zbytek mu nechat volný. Dají se použít 4k sektory, což je kolikrát docela dobrý nápad, ale musíš to mít správně zarovnané. Při 4k sektorech ti soubory žerou o malilinko víc místa, protože i ten nejmenší najednou zabírá 4k, ale funguje to jako zajímavá optimalizace. Další možnosti máš v oblasti FS, kdy pro některé oddíly(partition), můžeš nastavit parametry jako noatime a podobně. Další optimalizace můžeš udělat na straně databáze, občas se hodí prdnout TMP na nějaké jiné SSD a přenastavit parametry jako innodb_log_file_size. Další optimalizace se dají udělat třeba na straně SWAPu, do serveru přidáš paměť (64GB-128GB) a swap pošleš na rotační vrtichvost. Prostě se to dá celkem slušně poladit.
No a pak máš data, která se moc nemění videa, fotky, XLS...prostě běžný kancelářský trash a tam ti Copy on Write nemusí až tolik vadit.
EDIT: Ext4 by se měla zarovnávat by default ne? (Stejně to kontroluju.)
-
Zarovnání jsem vzdal, když jsem to chtěl řešit u TLC. Když totiž jsou v jedné buňce tři bity, velikost bloku nevychází jako mocnina dvou. (U nějakého konkrétního SSD nebo microSD to fakt bylo 3*2^n.) A jakékoliv zarovnání jde typicky dělat právě na mocniny dvou… Takže spíš předpokládám, že controller musí mít dobře vyřešenou situaci, kdy bloky zarovnané nejsou, protože není jak…
Možná by s tím nějaký controller teoreticky mohl dělat nějaké další kejkle a z bloku nějaké divné velikosti (rozhodně ne 2^n) udělat navenek blok velikosti 2^n (a zbylé bity ignorovat nebo využít třeba k checksum), ale o tom pochybuju – tuším, že dělat bloky o počtu buněk jiném než 2^n by přinášelo konstrukční komplikace, pokud by to mělo být efektivní. A udělat blok 2^n buněk, interně mít 3*2^n bitů, ale třetinu z toho ignorovat – to už rovnou můžeme mít 2-bit MLC.
-
No ty bloky dat u TLC nemusí nutně mít velikost jako násobek tří, protože na TLC nejsou přímo data, ale data+opravný kód, na SSD typicky LDPC
https://en.wikipedia.org/wiki/Low-density_parity-check_code
-
EDIT: Ext4 by se měla zarovnávat by default ne? (Stejně to kontroluju.)
Zarovnavaji se partisny, coz resi fdisk tim, ze je start vzdy nasobek 1MiB hranic, 2048 sektoru (* 512 BPS)
Vevnitr FS by mela byt struktura uz ciste v nasobcich alokacnich jednotek (clusteru, bloku), coz je 4KiB+
Nektere systemy maji zvlast header-area a pak maj neco jako data-offset.. potkal jsem se s tim u mdraidu. Muze to byt k prospechu i neprospechu, co se zarovnavani tyce.
-
Nad tím, že to nemusí být nutně násobek tří, jsem uvažoval, ale zároveň to těžko bude mocnina dvou. Pokud by to měla být mocnina dvou, potom vidím dvě možnosti:
a. Počet paměťových buněk v jednom bloku nebude mocnina dvou. Tady tuším různé praktické konstrukční problémy. Jak by to tam bylo nadrátováno, jak by to vypadalo geometrický… A vlastně i ekonomické problémy – čip by musel být speciálně navržený pro TLC, což by znamenalo nejen další náklady na návrh, ale poněkud by to omezovalo binning (tzn. vyrobí se hromada čipů, roztřídí se podle kvality, a až nakonec se rozhodne, který čip se použije kam).
b. Navenek se použije jen ⅔ kapacity, čímž s TLC dostaneme stejnou kapacitu jako u 2-bit MLC. Teoreticky možné, ale tuším, že motivace pro TLC směřovaly jiným směrem…
-
Zarovnávat je vhodné na Erase Blocky, více viz https://superuser.com/questions/1243559/is-partition-alignment-to-ssd-erase-block-size-pointless
Další věc jsou velikost logických bloků a fyzických bloků. To už rotační disky začínaly pracovat s bloky 4KiB (Advanced format nebo jak se tomu říká), i když dál při komunikaci se adresovalo a adresuje jako 512B (logická velikost sektoru). Jak se začalo se SSD, tak ty vhodné zarovnávací velikosti rostou. fdisk by default zarovnává na hranicích 1MiB.
-
Nad tím, že to nemusí být nutně násobek tří, jsem uvažoval, ale zároveň to těžko bude mocnina dvou. Pokud by to měla být mocnina dvou, potom vidím dvě možnosti:
a. Počet paměťových buněk v jednom bloku nebude mocnina dvou. Tady tuším různé praktické konstrukční problémy. Jak by to tam bylo nadrátováno, jak by to vypadalo geometrický… A vlastně i ekonomické problémy – čip by musel být speciálně navržený pro TLC, což by znamenalo nejen další náklady na návrh, ale poněkud by to omezovalo binning (tzn. vyrobí se hromada čipů, roztřídí se podle kvality, a až nakonec se rozhodne, který čip se použije kam).
b. Navenek se použije jen ⅔ kapacity, čímž s TLC dostaneme stejnou kapacitu jako u 2-bit MLC. Teoreticky možné, ale tuším, že motivace pro TLC směřovaly jiným směrem…
To je zbytecne o tom uvazovat takhle "naivne". Moderni FTL pouziva jako backend (smerem k NAND) spis zurnalovaci pristup - erase/append, kde pocet ani velikost techto kalisku ("zones") nemusi byt mocninou dvou, proste nektere adresy zustanou nevyuzity. V idealne naivnim TLC pripade mate napr. 3 x 64KiO = 192KiB (namisto 256KiB, tudiz se lokalni in-zone adresa vyuziva jen z casti, ale o to vice jich bude, pro dosazeni celkove efektivni kapacity. A nektere disky v ramci kalisku data komprimovali, takze je mozne, ze se do takoveho 192KiB fyzickeho backendu dalo ulozit rekneme 256KiB obsahu - pak ten volny adresni prostor dava jeste vetsi smysl (resp. pridava dalsi druh adres v ramci FTL).
Do toho vseho pak vstupuje fakt, ze velikost radku v NAND nemusi (a nikdy nebyla) mocninou dvou - vzdy tam bylo par extra desitek ci stovek slov prostoru pro samoopravne kody. A dalsi fakt je, ze v 3D / V-NAND vstupuje do cele translace jeste pocet vrstev, ktere sdili urcite featury, a ty taky nejsou mocninou dvou.
Plus tam pridejte SLC-cache, kterymi se vykonove propady trocha umirnuji (a la setrvacnik/dvouhmota na motoru), takze hledat nejakou spojitost mezi LBA kterymi se SSD prezentuje, a fyzickou strukturou NAND cipu je dneska totalne nemozne.
-
SSD disk zajímají jeho interní sektory.
Dovedete si představit, jak by musela být ohromná tabulka jednotlivých přemapovaných buněk?
SSD disk zajímá jeho sektor a přemapovává interní sektory, BTW, nedělá to nějak sofistikovaně!
Disk má k dispozici sektory: 1xxxxxxxxxxXXXX až třeba (1TB děleno jeho interními sektory) a všechny jsou pro SSD disk přístupné. Malá x jsou sektory, které OS vidí a velká X operační systém běžně nevidí, ale jsou nástroje, kterými je můžete pro operační systém zpřístupnit.
Dokonce to jde až tak daleko, že Intel jednu dobu vydával stejná SSD a jejich určení měnil jen počtem vyhrazených buněk. Například Intel SSD 160 GB (nebo 180ka) byla jen 240ka s velkým množstvím náhradních sektorů. Ale byla dražší a už jí snad označoval "DC" :-D
Takže v principu tě vůbec nezajímá to, jak si to SSD porcuje interně, ostatně firmware SSD musí být schopný se vypořádat s potřebou jak 512kB sektorů, tak i s přepnutím na 520kB sektory (které potřebují různé RAID). Ty se jen potřebuješ trefit na jeho interní sektory, které jsou SKUTEČNĚ VĚTŠÍ, protože tam potřebuješ narvat dost informací o stavu sektorů a opravné kódy.
Za mě, kontrolu zarovnání nevzdávat...
-
viz https://superuser.com/questions/1243559/is-partition-alignment-to-ssd-erase-block-size-pointless
To je velmi zajímavé čtení:
voids the need for partition alignment
My final advice is to align partitions to respect erase-blocks layout.
A je tam zajímavý odkaz, kdy přepnul disk na 4kB stránky.
Kontrola: nvme id-ns -H /dev/nvme0n1mujdisk
Přepnutí s formátem: nvme format --lbaf=1 /dev/nvme0n1mujdisk
Zdroj: https://www.bjonnh.net/article/20210721_nvme4k/
LOL ssd se mu zrychlilo o 10% zdarma :-D 10% výkonu zdarma...to není špatné :-)
Díky za post, velmi užitečné!
-
...
Díky za post, velmi užitečné!
Přiznám se, že takhle pečlivě jsem to ani nečetl. :-) Koukám na můj NVME v notebooku a tam by to asi bylo vhodnější přeformátovat také, ale kouknul jsem na nějaký server, kde jsou nějaké 2T Samsungy a tam je u obou formátů Best. Tak tam by to asi nepomohlo. Díky za link s tímhle hintem, do budoucna to použiju.
-
Totiž při použití ZFS pozoruji v smartctl řádově větší zápisy než při použití ext4. Takže i lepší disk se ZFS by při mém použití měl mít životnost jen několik let. Není to ale jen chyba měření?
Da discích běží databáze mysql s hodně zápisy a updaty. Také je mi divné, že podobný problém nikdo další nehlásí.
Osobně bych asi zkusil ty dvě věci oddělit od sebe a udělal nějaký pokus s identickou operací (hromadu insertů, updatů) nad nějakou pokusnou databází uloženou na ZFS resp. ext4 a pak mrknout na /proc/diskstats
https://www.kernel.org/doc/Documentation/ABI/testing/procfs-diskstats
https://www.kernel.org/doc/Documentation/iostats.txt
Asi budou i nějaké nástroje, co to umí hezky ukázat, já když to potřeboval, tak jsem to vždycky nějak vysekal přes awk.
Čekal bych že tam bude nějaká aplifikace kvůli CoW, ale nezdá se mi, že by to měl být řád. Ale můžu se samozřejmě v konkrétním případě plést.
CoW se na databáze nedoporučovalo a na BTRFS to jde i pro jednotlivé soubory/adresáře/globálně vypnout.
To u ZFS nejde, dá se třeba ladit recordsize, aby to ideálně odpovídalo databázové stránce, ale vypnout CoW přes chattr nejde.
Ještě se u ZFS třeba dá optimalizovat práce se ZIL pro logbias=throughput.
1. Některá data si ZFS může prvně zapsat do ZFS intent log, a teprve potom je skutečně zapsat. (I když si nejsem jistý, jestli se to používá i na SSD.)
ZIL se použije vždy při synchronních zápisech do FS. Nezáleží na tom, jestli je pod tím rotační disk nebo SSD, ale jak byl otevřený soubor resp. file handle.
To se v mysql dá přepínat direktivami na ladění innodb. Další věc je, že innodb má ve výchozím nastavení povolený innodb_doublewrite, takže pokud pak ještě ty transakce pro každý zápis dělá i FS podtím, je to zbytečné jak z hlediska výkonu, tak počtu zápisů.
Já abych se upřímně přiznal, tak jsem se ZFS v reálu pracoval jen na FreeBSD a Solaris/Illumos, takže je možné, že na Linuxu bude pro mysql možné ještě nějaké další tweakování innodb. Vzpomínám si, že na tohle téma byly nějaké návody od Percony a Let's Encrypt, kde to bylo do docela rozepsané.
-
Jinak s těmi SSDčky a hraní si s velikostí bloku FS resp. zarovnáváním na nějaké jiné hodnoty než host nativní (abych se třeba trefil na nějakou vnitřní velikost erase bloku) nemám moc zkušeností, vždycky jsem se snažil nastavit min. velikost zápisu FS buď na 4 nebo 8k podle modelu SSD. A bral to spíš tak jak píše RDa, tzn. že tam je při zápisu ještě FTL mapování, SLC cache a vnitřní procesy, které stejně neovlivním. Nedávalo mi až takový smysl s tím laborovat.
Ale případný benefit bude asi záležet na workloadu a konktétním modelu SSD.
SSDčka jsou zrádná, QLC ti v serveru chcípá před očima. TLCčka jdou, ale pokud to není serverový disk, nemůžeš použít celou jeho kapacitu, ale vyhradit tak maximálně 80% a zbytek mu nechat volný.
Tohle mi přijde zajímavý point, u kterého jsem si nikdy nebyl úplně jistý, a měl na to v konverzaci vždy minimálně dvě odpovědi :)
- nechávat volné nealokované místo (nad rámec volného místa pro zachování výkonu FS, kvůli alokátoru, fragmentaci) má smysl, protože se všechny volné, "trimované" buňky můžou použít na remapování.
- nenechávat, protože se remapuje pouze s buňkami z overprovisioning oblasti nad rámec logické kapacity zařízení (např 10% kapacity navíc). Což je dané typem, kategorií SSD a návrhem výrobce.
Nemáte nějaký autoritativní zdroj, kde by tohle chování bylo popsané? I vzhledem k tom, že se člověk do firmware, nebo FTL mapy jen tak nepodívá.
-
Autoritativní zdroj ne, ale několik vysvětlení ano.
Předně, při zaplnění disku z >90% už není mnoho sektorů, na které se dá zapisovat a prakticky se potom přepisují pořád ty stejné, což likviduje části SSD disku velmi nerovnoměrně, swapují se tam data, každé nabobtnání logu používá tyto bloky. A pokud chtěl být výrobce disku cool, možná začne stěhovat obsazené bloky. Ty z málo opotřebovaných bloků na ty hodně opotřebované, což bohužel nemusí být vůbec ideální, sice se mu uvolní ty málo opotřebované bloky, ale disk netuší, jak dlouho ta data na těch oježděných sektorech zůstanou, třeba je to jen temp, který má u notebooku s Widlema XYGB. Disk interně začne stěhovat kusy souborů na víc opotřebované bloky, aby na ty málo opotřebované bloky zapsal zalogované události... podle chytrosti disku a systému se mohou dít zajímavé věci.
Dále to je o trimování, jedním z doporučených postupů je mít trimování jako naplánovanou úlohu, protože trim při startu systému funguje tak někde u Widlí, ale pokud stroj moc nerestartujete, tak se Trim třeba i dlouho neudělá. Už dlouho se některé SSD disky obejdou bez TRIMu, ale jestli to lze generalizovat? No nevím.
Mimochodem, ten TRIM a volné místo spolu souvisí, pokud systém vidí jen 80% kapacity, nemůže se mi stát, že bych měl disk přeplněný, protože TRIM neprobíhá nebo protože je prostě přeplněný. Operační systém samotného SSD disku má pořád k dispozici cca 15-20% volné kapacity, na kterou OS nedosáhne. U serverových disků to neřeším, pokud má disk 3DWPD, protože jeho skutečná kapacita je nejspíš dvoj-trojnásobná, oproti tomu, co vidí systém.
Dále, jak jsem psal, řada disků se liší jen tím, jak velká je záloha sektorů. Např. některé disky měly kapacitu 120 nebo 128 GB a skutečná kapacita 130 GB, rozdíl byl ve velikosti záložního místa. Takže na-alokovat poněkud méně disku určitě neškodí.
Dále, u zákaznických disků, typicky QLC, se používá SLC cache, která ovšem zásadně nebydlí na "rezervních sektorech", pokud se disk zaplní na 80-90%, SLC cache už není k dispozici a výkon jde do kytek velmi zásadně. Naopak, pokud mám laciný 1 TB disk a alokováno jen 850 GB, pořád mám cca 40-80 GB pro SLC cache, byť je disk téměř plný.
Ad QLC disky s SLC cache:
Třeba stařičký (a jeden zprvních QLC) Intel 660p přišel s SLC cache a hrůzostrašnou hodnotou 0.1 DPWD (což je jedna TŘICETINA hodnoty serverového disku). Velikost SLC cache je rozdílná, viz tabulka: https://www.anandtech.com/show/13078/the-intel-ssd-660p-ssd-review-qlc-nand-arrives
Například v rozmezí 12 GB - 140 GB pro 1TB model, hodnota se mění v závislosti na zaplnění disku. Při zaplnění disku se navíc zátěž nerozkládá rovnoměrně, ale "ojíždí se" ten zbytek. Ideální by samozřejmě bylo vyhradit například 50% kapacity disku jako rezervu, ale to by z 1 TB disku byla jen 512GB... Takže těch 80-85-90% + zbytek ať si sežere operák mi přijde fajn.
A teď objev Ameriky
Jestliže ten disk má 1TB celkové kapacity a SLC cache o velikosti 140 GB bydlí na něm, KOLIK MÍSTA ZABÍRÁ SLC CACHE? Ano, modří už vědí, 140 GB * 4 = 560 GB! Takže z krásného 1TB disku je ve výchozím stavu 560 GB vyhrazeno pro SLC cache o kapacitě 140 GB :-D to jsou počty, to si člověk neuvědomí! Je tady logické, že po zapsání 500 GB na disk se na něj už nevejde 140 GB SLC cache, takže ta velmi rychle klesá...no vlastně rychleji, protože QLC někdy doslova chcípá před očima...
-
Btw mrknete se treba i sem:
https://files.futurememorystorage.com/proceedings/2019/08-05-Monday/20190805_PreConfG_Stoica.pdf
Co treba vetsina lidi netusi, je, ze jak se MLC pameti programuji - takze zatimco do SLC pameti se data zapisuji primo (tedy, uvazujme ze je pamet smazana predem), tak u MLC,TLC,QLC se zapisuji na vicekrat - zapis nepracuje s analogovymi urovnemi ruznymi pro ruzne "multi-bity", ale vzdy se zapisuje jedna logicka/binarni hodnota, jen z ruzne bitove roviny.
Pro MLC se zapisuje na 2x, prvni faze zapise (nebo nezapise) naboj ktery je roven pulce max urovne, druha faze zapisu pouze pripise dalsi - nyni jiz polovicni uroven predesle faze. Pro TLC se zapisuje na 3x - vzdy s mensi a mensi silou. A obdobne, pro QLC, zapis probiha az 4x do te same stranky.
Takze ony TLC nezapisuji 3 bity do bunky najednou, spis se to chova jako vicestopa paska - logicky je pamet 3x delsi, protoze ma 3x vice bitovych rovin, ktere se daji zapsat. Jen si disk musi vest trocha poradek, protoze se mazou vsechny bitove roviny naraz :D
(z tohoto principu je pak videt jak panove prisli na SLC cache - vyuzije se pouze jedna zapisova faze)
A ted - proc jsou vlastne ty TLC/QLC pomale - sila zapisu nejde uplne presne nastavit uz v techto mezich, takze se pouziva ponekud brute force pristup. Do bunek se pritukne nejake male kvantum - pak se precte, jestli to sedi tam kde to ma, tak tam se onen bit uz nezapisuje, ale kde to nesedi, tam se pritukne jeste kousek -
https://files.futurememorystorage.com/proceedings/2018/20180808_FTEC-202-1_Ye.pdf
-
A je tam zajímavý odkaz, kdy přepnul disk na 4kB stránky.
Kontrola: nvme id-ns -H /dev/nvme0n1mujdisk
Přepnutí s formátem: nvme format --lbaf=1 /dev/nvme0n1mujdisk
Zdroj: https://www.bjonnh.net/article/20210721_nvme4k/
Zajímavé, jeden disk má jen 512B, druhý jen 4k a třetí (Kingston 2TB) umí oboje a teď je 512B, tak ho přepnu. Díky
-
Zajímavé, jeden disk má jen 512B, druhý jen 4k a třetí (Kingston 2TB) umí oboje a teď je 512B, tak ho přepnu. Díky
Prosím, dej nějaký feedback, jestli se nějak zlepšil výkon.
Taky mám pár disků, které má asi smysl přepnout, ale bez měření není posvícení :-D
Dík!
-
A je tam zajímavý odkaz, kdy přepnul disk na 4kB stránky.
Kontrola: nvme id-ns -H /dev/nvme0n1mujdisk
Přepnutí s formátem: nvme format --lbaf=1 /dev/nvme0n1mujdisk
Zdroj: https://www.bjonnh.net/article/20210721_nvme4k/
Zajímavé, jeden disk má jen 512B, druhý jen 4k a třetí (Kingston 2TB) umí oboje a teď je 512B, tak ho přepnu. Díky
Podle mne získání 10% procent výkonu není moc důležité. Jde spíše o to lépe vyhovuje životnosti disku. A zde může být lepší, když jde na disk zapsat jen 512B, když se např. updatuje index databáze. Nebo jak to vlastně funguje?
A také jde o to, co se vlastně započítá, jestli jeden blok, nebo rovnou bloků 8 kvůli jedinému zápisu.
-
Autoritativní zdroj ne, ale několik vysvětlení ano.
Díky za rozepsání. A ano tohle o té dynamické SLC jsem věděl, a je i jasné, že když dochází volné paměťové buňky, tak obecně roste WAF. I když samozřejmě ten praktický dopad na výkon bude strašně záležet na workloadu a nemusí to být tak děsivé, jako když tam někdo kontinuálně jede sekvenční zápisy v nějaké syntetickém testu.
Jinak obecně já se taky v praxi snažím nechávat rozumné množství volného místa. I když, přiznám se, dělal jsem to i dekády zpátky, primárně kvůli fragmentaci a šíleným přístupovým dobám, no a přenesl jsem si to i na SSD. Nedělám menší oddíly, ale spíš využívám množství rezervovaných bloků (ext4, XFS) nebo kvóty, pokud to nemá nějaké vedlejší účinky (měl jsem třeba problém u BTRFS s kvótami a větším množství snapshotů).
Šlo mi v otázce čistě o ten konkrétní mechanismus a potvrzení, že se všechny trimované, unmapované bloky vždycky vrací do nějakého poolu, odkud se pak kdykoliv použijí na dyn. SLC, GC, remapování atp.
Ale bude to tak, je to logické a nakonec jsem našel i něco jako "autoritativní" článek s odkazy
https://sabrent.com/blogs/storage/ssd-overprovisioning
Je toho víc, jen asi když jsem to před lety hledal, tak jsem zřejmě neměl správnou terminologii :)
Někde to např. označují jako explicit (bloky rezervované výrobcem) a implicit (otrimované bloky volného místa na FS) overprovisioning.
A shodou okolností v tenhle konkrétní Intel P660 v 2TB verzi jsem použil před lety do jedné video střižny. Byl to první rozumně dostupný QLC model v těchhle kapacitách. Slouží tam jako render cache, takže jsem to bral tak, že je tam mnohem víc čtení než zápisů a navíc žádná kritická data, kdyby to odešlo vzhledem k výdrži QLC. Zatím funguje (bude to 6-7 let už si to přesně nepamatuju).
Btw mrknete se treba i sem:
Taky díky, zajímavé. Také jsem v poslední době procházel různé papery, prezentace atp. ohledně SSD. Upřímně mě až překvapil ten vývoj a sofistikovanost ohledně řídících algoritmů uvnitř SSD. A nejen kvůli použití těch 3D buňek, kde je třeba brát víc v potaz ty fyzické atributy ukládání a zohledňovat je v metadatech, ale i třeba velikosti dnešních největších SSD (např. 32TB v enterprise řadách), kdy už to vyžaduje relativně extrémní velikosti těch map a metadat, což přináší další výzvy, pokud to nejde řešit jen hrubou silou/velikostí DRAM cache. Nebo např. implementace chytrého klasifikátoru různých druhů IO operací z hosta, který pak ovlivňuje spousty věcí uvnitř SSD. Počínaje výběrem buňky při zápisu, přes různou práci s SLC (v určitých případech ji přeskakuje a jde rovnou do TLC/QLC) až po scheduling interních přesunů dat mezi buňkami, které pak musí brát v potaz přesně ty fyz. parametry 3D vrstev, počet zápisů a dobu od posledního atp. A ideálně by to mělo co nejmíň ovlivnit výkon z hosta pro aktuální workload a samozřejmě zaručit konzistenci třeba při případném výpadku napájení.
Jsou k dispozici i papery, kdy na tyhle koordinace vyvíjí a testují používání agentů s reinforced learningem. Takže až uvidíme "AI" disky, tak to nebude tak daleko od pravdy ;)
Stejně jako snahy o bližší spolupráci aplikace a souborového systému (např. Log2FS) s tím firmware v SSD, kdy to může výrazně zvýšit efektivitu, zvlášť pokud se na všech třech zmíněných úrovních řeší podobná věc (např. nějaká forma Write Ahead Loggingu), optimalizace využití front, eliminace zbytečného kopírování mezi buffery atp.
Spousta věci :)
-
Někdo tu řekl, že na 10% výkonu nezáleží, ALE!!!
U něčího domácího počítače na trollení, filmy a péčko to je vážně fuk.
Ale u serveru na databázi to fakt jedno není:
10% výkonu dělá jen formát disku 512B vs 4kB, taková malá změna a naprosto zadarmo... (ZADARMO...)
10% další optimalizace (omezení zápisů, noatime... https://wiki.debian.org/SSDOptimization (https://wiki.debian.org/SSDOptimization)
15% výběr vhodného FS: https://www.phoronix.com/review/linux-58-filesystems/2 (https://www.phoronix.com/review/linux-58-filesystems/2)
(https://openbenchmarking.org/embed.php?i=2007018-NE-SSDSTORAG93&sha=3f8807c&p=2)
15% udělá přidání dalšího SSD na oddělení logu databáze
10% udělá optimalizace databáze na úrovni parametrů instance
No a najednou je to rozdíl 5 000 vs 10 000 obsloužených klientů, aniž by se v tom vrtal programátor a nějak to optimalizoval.
-
Šlo mi v otázce čistě o ten konkrétní mechanismus a potvrzení, že se všechny trimované, unmapované bloky vždycky vrací do nějakého poolu, odkud se pak kdykoliv použijí na dyn. SLC, GC, remapování atp.
Něco takového jsem si vyzkoušel při změně SSD (Samsung 990 Pro). Překopíroval jsem obsah starého SSD pomocí dd a podíval se do smartctl na obsazení. Zjevně se i nepoužité místo zapsalo jako použité, tedy z nějakého důvodu SSD controller nenapadlo samé nuly zapsat jako díru. Nicméně pak jsem se pustil do trimování (můj setup byl převážně dm-crypt -> LVM -> ext4, takže to bylo trochu komplikovanější) a místo se uvolnilo. Obsazeno potom bylo ± jako na starém SSD.
Jiné modely se mohou chovat mírně odlišně, ale u moderních SSD bych nečekal fundamentální rozdíl…
EDIT: Pokud tam bude nějaký háček, tak bych čekal maximálně něco jako že by bylo potřeba několik po sobě jdoucích volných bloků, aby došlo ke skutečnému uvolnění, protože velikost erase bloku bude větší.
-
https://forum.root.cz/index.php?action=post;topic=29358.15;last_msg=408311#postmodify
Podle mne získání 10% procent výkonu není moc důležité. Jde spíše o to lépe vyhovuje životnosti disku. A zde může být lepší, když jde na disk zapsat jen 512B, když se např. updatuje index databáze. Nebo jak to vlastně funguje?
A také jde o to, co se vlastně započítá, jestli jeden blok, nebo rovnou bloků 8 kvůli jedinému zápisu.
Ty čítače ve SMARTu z NVME disku nekecají, jsou to dva standardizované atributy (07h, 08h), které říkají kolik dat šlo při čtení resp. zápisu z hosta (ne kolik se zapsalo na NAND buňky). Je to vždy přepočítáno na bloky 512 bajtů.
Tzn. když se zapíše jeden 4k request, tak se čítač inkrementuje o 8, pokud se zapíše čtyři 16k requesty, tak se inkrementuje o 32 atp. Z hlediska tohohle akumulovaného čítače je víceméně jedno, jaké délky requestů se používají a případně jaká je minimální délka v systému (jestli 512 B nebo 4 kB).
Navíc jsou tam dva další čítače (09h, 0Ah), Host Read Commands a Host Write Commands. Když podělíte velikost (v bajtech) z předchozích atributů těmihle hodnotami, dostanete průměrnou délku requestu.
Pokud byste chtěl zjistit kolik se skutečně zapsalo do buněk a potažmo, jaká je amplifikace zápisu (WAF) v hardware, tak to není ve standardních atributech v NVME disku. To je typicky v detailnějším c0 logu, který musíte vytáhnout a dekódovat přes konkrétní utilitu v nvmi-cli, ale formát je specifický pro každého výrobce, takže např. pro Intel to bude něco jako - nvme intel smart-log-add
https://manpages.debian.org/testing/nvme-cli/nvme-intel-smart-log-add.1.en.html
To pak zobrazí i celková data zapsaná data do buněk (obvykle počet 32MB bloků).
Hardwarový WAF ovlivníte primárně tím, co jsme tu naťukli v ostatních postech.. Tzn. třeba podle situace např. volným místem na FS a pravidelným trimováním.
Ale to, jak jsem to pochopil, není ta hlavní potíž. Vy spíš řešíte zvýšení WAF a množství zápisů, kvůli nastavení filesystémů, resp. databáze.
Jak zaznělo v předchozích postech, tak tohle bude primárně věc souběhu určitých mechanismů v ZFS a v innodb, které se pak projeví tak, že se do toho blok. zařízení zapisuje mnohem víc, než se standardními souborovými systémy.
Něco už tu padlo. Innodb má standardně zapnutý doublewrite do separátního souboru, tzn. dělá to víceméně totéž jako CoW u ZFS. Další věc je, že když se dat. soubor, index, nebo ten DW soubor otevře v synchronním řežimu, tak to na ZFS jede vždy přes ZIL (což je takový specifický žurnál buď v datasetu, nebo na samostatném zařízení). Data jdou nejdřív tam, pak se potvrdí zápis tomu procesu a následně zapíší na cílové místo v datasetu. Takže zas o zápis víc. Když už se použije ZIL, tak se dá ozkoušet různé nastavení volby logbias.
Dají se pak samozřejmě ladit i další parametry jak na úrovni ZFS, tak innodb, které nemusí nutně amplifikovat počet zápisů, ale mohou v určitých situací negativně ovlivnit výkon nebo třeba i spolehlivost ukládání dat, pokud se to rozhasí. Např. metoda synchronizace (flushování bufferů), ZFS nemá implementovaný O_DIRECT (vrací, že ano, takže nespadne aplikace, ale nechová se jako na klasickém fs), další věc je to nastavení bufferů, práh, kdy to začne flushovat, úroveň paralelizace atp. Na určitých konfiguracích, kde je třeba agresivnější bufferování v innodb může mít smysl v ZFS datasetu vypnout fakticky vypnout ARC pro data.
Relevantní volby jsou popsány přímo v dokumentaci OpenZFS a je tam i od
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#innodb
Případně aktualizovaný dokument o výkonu u Percony: https://www.percona.com/blog/mysql-zfs-performance-update/
Stran velikosti těch bloků, to je asi další téma (a držel bych se toho defaultu, ashift podle nativní velikosti na SSD - např. 4k, recordsize na datasetu podle velikosti stránky innodb), ale jiné nastavení by nemělo primárně způsobovat ten zásadně vyšší WAF.
Jak jsem zmiňoval, kdybych si to měl testovat a porovnávat s EXT4, potom, co budu měnit jednotlivé volby. Vůbec na počítání zápisů není potřeba to konkrétní SSD, udělal bych nějakou testovací databázi, čerstvé ext4 a ZFS třeba nad nějakými loop devicey a odečítal bych to rovnou z /proc/diskstats.. Dá se to zapéct rovnou do nějakého skriptu, co odečte aktuální hodnotu čítače s počtem zápisů, provede operaci s mysql klientem (nějaký SQL skript s insert, update, delete např.) a pak zas zjistí aktuální počet a odečte předchozí hodnotu. ZFS bude mít víc I/O než ext4, ale nemělo by to být 10x.
Uff, trochu delší :)
-
Něco takového jsem si vyzkoušel při změně SSD (Samsung 990 Pro). Překopíroval jsem obsah starého SSD pomocí dd a podíval se do smartctl na obsazení. Zjevně se i nepoužité místo zapsalo jako použité, tedy z nějakého důvodu SSD controller nenapadlo samé nuly zapsat jako díru. Nicméně pak jsem se pustil do trimování (můj setup byl převážně dm-crypt -> LVM -> ext4, takže to bylo trochu komplikovanější) a místo se uvolnilo. Obsazeno potom bylo ± jako na starém SSD.
Jiné modely se mohou chovat mírně odlišně, ale u moderních SSD bych nečekal fundamentální rozdíl…
EDIT: Pokud tam bude nějaký háček, tak bych čekal maximálně něco jako že by bylo potřeba několik po sobě jdoucích volných bloků, aby došlo ke skutečnému uvolnění, protože velikost erase bloku bude větší.
Díky, za praktické potvrzení. To s tím celým P/E blokem by taky dávalo smysl, akorát to samozřejmě komplikuje fakt, že díky FTL mapě to nemusí být po sobě jdoucí logické bloky. Ale to v zásadě asi nic nemění.
-
Tzn. když se zapíše jeden 4k request, tak se čítač inkrementuje o 8, pokud se zapíše čtyři 16k requesty, tak se inkrementuje o 32
To mělo být samozřejmě 4 x 16 kB = 128 x 512 B. Původní post už nejde opravit a navíc, jak na to teď koukám, tak se mi tam ještě nějak zapeklo prapodivné url na začátku. Pardon.
-
Jsou k dispozici i papery, kdy na tyhle koordinace vyvíjí a testují používání agentů s reinforced learningem. Takže až uvidíme "AI" disky, tak to nebude tak daleko od pravdy ;)
Stejně jako snahy o bližší spolupráci aplikace a souborového systému (např. Log2FS) s tím firmware v SSD, kdy to může výrazně zvýšit efektivitu, zvlášť pokud se na všech třech zmíněných úrovních řeší podobná věc (např. nějaká forma Write Ahead Loggingu), optimalizace využití front, eliminace zbytečného kopírování mezi buffery atp.
Spousta věci :)
Tak moderni uloziste maji api zvane ZNS - zoned namespaces, abstrakci ktera je precejenom bliz k rezimu prace SSD disku (erase,append) -
https://www.snia.org/educational-library/zoned-namespaces-zns-ssds-disrupting-storage-industry-2020
Tim se odbremeni z fw a cpu v disku velika cast FTL, ktera jak zminujete je rezine docela narocna uz na velkych discich. Namisto toho, aby SSD resilo kam s kazdym bajtem, tak resi jenom velice hrube tu alokaci - zony jsou imho nekolikanasobne vetsi nez typicke nativni erase bloky.
Akurat nad tim nedokazou pracovat nativne klasicke blokove orientovane reseni (filesystemy, aplikace), ale je nutno prijit s novymi resenimi. Anebo proste vyresit FTL na strane hostu a emulovat pak block device.
-
Autoritativní zdroj ne, ale několik vysvětlení ano.
Předně, při zaplnění disku z >90% už není mnoho sektorů, na které se dá zapisovat a prakticky se potom přepisují pořád ty stejné, což likviduje části SSD disku velmi nerovnoměrně, swapují se tam data, každé nabobtnání logu používá tyto bloky. A pokud chtěl být výrobce disku cool, možná začne stěhovat obsazené bloky. Ty z málo opotřebovaných bloků na ty hodně opotřebované, což bohužel nemusí být vůbec ideální, sice se mu uvolní ty málo opotřebované bloky, ale disk netuší, jak dlouho ta data na těch oježděných sektorech zůstanou, třeba je to jen temp, který má u notebooku s Widlema XYGB. Disk interně začne stěhovat kusy souborů na víc opotřebované bloky, aby na ty málo opotřebované bloky zapsal zalogované události... podle chytrosti disku a systému se mohou dít zajímavé věci.
Pri zaplneni disku sa neprepisuju stale rovnake sektory. SSD si to na pzoadi menezuje aby tie sektory boli rovnako opotrebovane a data prehadzuje medzi sektormi. Nieje to o tom, ci chce byt vyrobca cool alebo nie. To je zakladna vec, ktoru robi a bez toho by SSD-cka mali nizsiu zivotnost. Ano je to jedna z chytrosti disku. Pouziva nato aj spare area - kapacitu navyse, ktora je pre operacny system skryta.
Mimochodem, ten TRIM a volné místo spolu souvisí, pokud systém vidí jen 80% kapacity, nemůže se mi stát, že bych měl disk přeplněný, protože TRIM neprobíhá nebo protože je prostě přeplněný. Operační systém samotného SSD disku má pořád k dispozici cca 15-20% volné kapacity, na kterou OS nedosáhne. U serverových disků to neřeším, pokud má disk 3DWPD, protože jeho skutečná kapacita je nejspíš dvoj-trojnásobná, oproti tomu, co vidí systém.
S Trimom nieje problem aj pri zpalnenom disku prave vdaka spare area.
U 3DWPD SSD urcite nieje jeho fyzicka kapacita dvoj-trojnasobna(spare area nema nasobky deklarovanej kapacity SSD). 3DWPD nieje v podstate nic a fyzicka kapacita je len zhruba o tretinu vecsia. S narastom DWPD narasta aj spare area(pomer medzi fyzickou a deklarovanou kapacitou). SSD spare area pouziva na zvysenie zivotnosti a vykonu. V podstate na svoj vnutorny manazment. Aktualne sa na wirte intensive SSD(+-60DWPD) pouziva TLC NAND ale v rezime SLC. Je to v podstate SLC SSD a tam spare area vdaka SLC nieje potrebne tak velke a znovu bude niekde na urovni tretiny. Pouzivaju sa tam ja specialnejsie verzie NAND flash vyrabane na starsom vyrobnom procese, ktory sam o sebe zvysuje zivotnost.
Dále, jak jsem psal, řada disků se liší jen tím, jak velká je záloha sektorů. Např. některé disky měly kapacitu 120 nebo 128 GB a skutečná kapacita 130 GB, rozdíl byl ve velikosti záložního místa. Takže na-alokovat poněkud méně disku určitě neškodí.
To je spare area. kazde SSD je fyzicky vecsie ako je jeho deklarovna kapacita. Ak si clovek kupi spravne SSD na svoje pouzitie, tak toto riesit nemusi. Niekedy to ale moze byt lacnesia cesta ako kupovat SSD s vecsim DWPD.
Dále, u zákaznických disků, typicky QLC, se používá SLC cache, která ovšem zásadně nebydlí na "rezervních sektorech", pokud se disk zaplní na 80-90%, SLC cache už není k dispozici a výkon jde do kytek velmi zásadně. Naopak, pokud mám laciný 1 TB disk a alokováno jen 850 GB, pořád mám cca 40-80 GB pro SLC cache, byť je disk téměř plný.
Ten vykon ide do kytek aj bez zaplnenia SSD a SLC cache. Rychlost SSD mimo sekencnych operacii je radikalne nizsia a SLC cache je ti vtedy nanic. V realnom pouzivani sa SLC cache az tak casto nevyuziva. SLC chace je viac marketingovka a dovod preco su medzi SSD realne male rozdiely. Aj medzigeneracne. Lacne SSD maju nizsi vykon vdaka DRAM less,menej vykonnemu a menej kanalovemu radicu a pouzitiu pomalsich/horsich NAND.
Zmensovat si SSD(zvecsovat spare area) kvoli vykonu nema vyznam. Ani kvoli zivotnosti. To sa riesilo v zaciatkoch SSD,kde sa strasne riesila obava o zivotnost. Potom sa prislo nato, ze je to zbytocnost a dnes to uz neriesi nikto a aj dnesne TLC maju zivotnost vyssiu ako pouzivatelia vyuziju.
-
Zmensovat si SSD(zvecsovat spare area) kvoli vykonu nema vyznam. Ani kvoli zivotnosti. To sa riesilo v zaciatkoch SSD,kde sa strasne riesila obava o zivotnost. Potom sa prislo nato, ze je to zbytocnost a dnes to uz neriesi nikto a aj dnesne TLC maju zivotnost vyssiu ako pouzivatelia vyuziju.
Souhlasim - ono to smysl melo kdyz ta zivotnost rapidne klesala zmensovanim procesu u klasickych NAND. Pak nastoupilo V-NAND a rozmery bunek zas narostli zpet na pouzitelnou uroven, protoze najednou tam bylo nekolik desitek vrstev, dnes uz kolem 192-250.
-
SLC cache – hádám, že se to využije třeba při instalaci většího programu. A obecně u většího zápisu. Myslím, že nejen u sekvenčního. Pochopil jsem to tak, že SSD prostě rychle háže data do paměťových buněk, jako by to bylo SLC, a potom je přerovná. (Ano, u TLC to vlastně znamená, že dojde ke čtyřikrát většímu opotřebení.) Celkem tomu odpovídal i můj experiment, kdy jsem pauznul dd ze starého SSD na nové, novému SSD chvíli dál rostla teplota, než začala klesat. (Od oka bych řekl, že to neodpovídalo tomu, že se teplo muselo rozšířit k senzorům. Na začátek zápisu to reagovalo mnohem rychleji než na konec.) Zjevně si přerovnávalo data ze SLC cache do TLC podoby.
Nevidím důvod, proč by se SLC cache nemohla využít při náhodném zápisu. Mohlo by to fungovat podobně jako ZFS intent log, prostě data zapisuju sekvenčně, jak mi přicházejí, a potom je přerovnám. Ale nemám potvrzeno, že to SSD reálně dělají. (A různá SSD se mohou chovat různě.)
A ještě přemýšlím, jestli zde nemůže být ukrytý střípek odpovědi na původní dotaz. Nevím, jestli se SLC cache používá pro každý prd, nebo je tam nějaká chytristika, která to použije, až se třeba dostatečně zaplní fronta pro zápis. Výhodou té chytristiky by bylo menší (čtvrtinové u TLC) opotřebení v situacích, kdy je zátěž malá. Nevýhodou je méně predikovatelné opotřebení, které bude záviset na tom, jestli zápis přišel ve větší dávce, nebo ne. A tady by potom mohlo mít vliv ZFS, které při přerovnání dat ze ZIL do výsledných lokací může udělat relativně větší zápis najednou. A tím by teoreticky mohlo překročit threshold pro využití SLC cache, čímž by zvýšilo write amplification factor. Ne nutně pro všechny zápisy, ale pro zápisy do ZIL asi ano.
Ale je to spekulace, možná to smete ze stolu třeba xsouku04 už jen tím, že jeho SSD nemá SLC cache. Nebo někdo jiný tím, že bude o SLC cache vědět více.
-
NVMe disky často lžou o velikosti svých sektorů - nejmenší zapisovatelné oblasti. Hlásí 512 B i když ve skutečnosti nejmenší data, které mohou zapsat jsou 4 KB nebo dokonce 8 KB....
Fakt? To ses hodne mimo ... uz roky sem nemel v ruce SSD ktere by melo blok mensi nez 64kB.
Dal, SSDcku je uplne jedno kolik dat zapise, to co pocita ... je POCET zapisu. TO je to oc tu bezi. Kazdy jeden libovolne maly zapis === je potreba zapsat CELY blok.
A tudiz, pokud SSD navenek tvrdi, ze jeden blok je 512B, pocita prave ten pocet bloku a pro ucely BFU jako ses ty to prevadi na GB. Navic to cislo je ciste orientacni = neznamena vubec nic.
ZFS (ani btrfs) NENASOBI mnoztvi zapisu. COW funguje tak, ze misto aby se prepsala existujici data, zapisou se do volneho mista === exaktne stejny jeden zapis. Pak se jen prislusny stary blok oznaci jako prazdny, coz je nejaka rezije navic, ale rozhodne ne nasobky. Vyrabi to samozrejme fragmentaci, coz je ale na SSD vicemene jedno, protoze SSD je fragmentovane z principu.
SSDčka jsou zrádná, QLC ti v serveru chcípá před očima. TLCčka jdou, ale pokud to není serverový disk, nemůžeš použít celou jeho kapacitu, ale vyhradit tak maximálně 80% a zbytek mu nechat volný.
Ale tomu SSDcku je uplne burt jestli ty bloky mas alokovany a volny nebo nealokovany a volny. Pouzije je tak i tak. Jen ty nemas pro pripad potreby cast kapacity. To je jediny ceho tim docilis.
Autoritativní zdroj ne, ale několik vysvětlení ano.
Předně, při zaplnění disku z >90% už není mnoho sektorů, na které se dá zapisovat a prakticky se potom přepisují pořád ty stejné, což likviduje části SSD disku velmi nerovnoměrně,...
Coz neni pravda, zjevne netusis jak to funguje. SSD i kdyz na nej bebudes zapisovat vubec, bude ve skutecnosti porat presunovat data ze? Proste proto, ze jinak zmizi. Takze jednou za cas veme blok, skopiruje ho jinam a ten puvodni oznaci jako volny. A dela to i prave z toho duvodu, aby se stale do stejnych bloku nezapisovalo.
Jinak receno, vsechny zapisy budou v prubehu casu rozlozeny prakticky idealne rovnomerne do vsech bloku SSD.
Problem zaplneneho SSD je uplne jinde. Spociva v tom, ze kdyz na nej posles zapis, nema moc volnych bloku, a bude muset velice pravdepodobne nejaky blok prepsat = skopirovat = cist a znova zapsat, coz samozrejme razantne zhorsi vykon.
TRIM open pouze a vyhradne ovlivnuje VYKON. Protoze kdyz SSD VI, ze je blok kompletne volny, tak VI, ze ho nemusi pripadne cist aby na nem zmenil jeden bajt jednoho souboru, coz bude delat, kdyz to nevi. Zapisovat bude tak jako tak do nejakeho jineho volneho bloku.
-
Plácáš...
-
Fakt? To ses hodne mimo ... uz roky sem nemel v ruce SSD ktere by melo blok mensi nez 64kB.
Jak se to dá poznat? Většina lidí co se o tom na internetu vyjadřuje si myslí, že nejmenší zapisovatelná velikost je 4,8 nebo 16 KB. Výrobci to raději nezmiňují.
Dal, SSDcku je uplne jedno kolik dat zapise, to co pocita ... je POCET zapisu. TO je to oc tu bezi. Kazdy jeden libovolne maly zapis === je potreba zapsat CELY blok.
Ano. To ale znamená, že SSD lze snadno odrovnat databází, kde se hrozně často updatuje, vkládá a maže.
MyISAM má velikost bloku prý 8 KB, Inodb 16 KB. Pokud by se ale ve skutečnosti vždy zapsalo 64 KB nebo víc, je to neskutečné plýtvání. V případě MyIsam je plýtvání skoro desetinásobné.
Napadá mne že možná není až tak problém v tom ZFS, ale v tom, že ty disky na kterých testuji ZFS (nové VMNE disky) jsou o 8 let novější oproti těm starým SATA SSD diskům (řada Kingston DC600M Enterprise) a tak mají podstatně větší bloky a tedy více se opotřebovávají. Je možné, že dnešní SSD disky mají třeba pětinásobně větší bloky než před deseti lety? A když připočtu nějaký overhead ZFS, mohla bych se dostat na destinásobné množství zapsaných dat.
A paradoxně těm starým diskům zbývá delší život než úplně novým.
Co se týče mého použití, nevadilo by mi že při výpadku elektřiny přijdu třeba o 10 vteřin dat. Dokonce i několik minut je OK. Jen databáze musí zůstat konzistentní. Potřeboval bych nějakou optimalizaci toho, aby se jedním zápisem na disk provedlo více změn naráz a tím se zvýšila rychlost a snížilo opotřebování disku. Je možné udělat něco pro tuhle optimalizaci v nastavení souborového systému nebo databáze?
-
Co se týče mého použití, nevadilo by mi že při výpadku elektřiny přijdu třeba o 10 vteřin dat. Dokonce i několik minut je OK. Jen databáze musí zůstat konzistentní. Potřeboval bych nějakou optimalizaci toho, aby se jedním zápisem na disk provedlo více změn naráz a tím se zvýšila rychlost a snížilo opotřebování disku. Je možné udělat něco pro tuhle optimalizaci v nastavení souborového systému nebo databáze?
A nepomuze k tomuto ucelu bateriove zalohovany ramdisk?
Videl jsem par custom reseni, ale taky takove ktere maji NVMe API a kapacitu cca 8GB. Ted uz jen najit FS, ktery se necha takhle nastavit.. pry ZFS?? Takze vlastne neprijdes o nic - pac ten write intent log by mel obsahovat bud kompletni transakce oddelene barierou, nebo posledni sadu operaci, ktera je polovicata (imho ta by se pak na uloziste commitnout nemela). Vyhodou toho ramdisku je, ze nema TBW limit, a jeho fw resi zalohovani/restore do shadow nand.
-
Co se týče mého použití, nevadilo by mi že při výpadku elektřiny přijdu třeba o 10 vteřin dat. Dokonce i několik minut je OK. Jen databáze musí zůstat konzistentní. Potřeboval bych nějakou optimalizaci toho, aby se jedním zápisem na disk provedlo více změn naráz a tím se zvýšila rychlost a snížilo opotřebování disku. Je možné udělat něco pro tuhle optimalizaci v nastavení souborového systému nebo databáze?
A nepomuze k tomuto ucelu bateriove zalohovany ramdisk?
Videl jsem par custom reseni, ale taky takove ktere maji NVMe API a kapacitu cca 8GB. Ted uz jen najit FS, ktery se necha takhle nastavit.. pry ZFS?? Takze vlastne neprijdes o nic - pac ten write intent log by mel obsahovat bud kompletni transakce oddelene barierou, nebo posledni sadu operaci, ktera je polovicata (imho ta by se pak na uloziste commitnout nemela). Vyhodou toho ramdisku je, ze nema TBW limit, a jeho fw resi zalohovani/restore do shadow nand.
Datacentrum má baterie i agregát. Ale někdy všechno může selhat, nebo se kousnout počítač. Ztráta těch dat ale u nás nevadí. Jen jde o to, omezit ty zápisy, aby se disky nezničili za dva roky.
-
Datacentrum má baterie i agregát. Ale někdy všechno může selhat, nebo se kousnout počítač. Ztráta těch dat ale u nás nevadí. Jen jde o to, omezit ty zápisy, aby se disky nezničili za dva roky.
Tak karta ma vlastni baterii i flash, kam si to transparentne odlozi az vypadne napajeni.
Otazka je zda umi ZFS fungovat tak, ze to do toho intent logu nabufferuje treba 7GB a pak pri flushi to cele zmerguje a vysype az finalni modifikace do flash pole, a az to cele probehne, tak se oznaci NVRAM jako uspesne commited a tim v tom bufferu uvolni misto.
Takze by to vlastne fungovalo jako anti-WAF, protoze nekolik zapisu na stejne LBA by to do flash pole poslalo jen jednou (finalni hodnotu z toho objemu 7GB logu.. cili zapis bude mensi nez 7G kdyz tam budou prepisovane stejne oblasti)
-
Fakt? To ses hodne mimo ... uz roky sem nemel v ruce SSD ktere by melo blok mensi nez 64kB.
Podle wiki gentoo zápis z roku 2019 bývá pages size 4-16 KB (nejmenší zapisovatelný blok dat), ale Erase blosk size (nejmenší data které je možné smazat) až 8 MiB. To se tak změnilo?
https://wiki.gentoo.org/wiki/SSD
-
Pre ukazku rozdiel medzi 1DWPD a 3DWPD pri cerstvov ydanych serverovskych SSD od solidigm(byvaly Intel)
1DWPD - 1.92TB
3DWPD - 1.6TB
O 320GB znizenie kapacity(zvysenie spare area) na zvysenie DWPD z 1 na 3. Takze ziadna dvoj-trojasobna fyzicka kapacita pri 3DWPD. Ten 1DWPD bude mat spare area odhadom okolo 200-300GB.
https://www.solidigm.com/content/dam/solidigm/en/site/products/data-center/product-briefs/ps1010-ps1030/solidigm-d7-ps1010-d7-ps1030-product-brief.pdf
K tej SLC cache. Pri nej som sa trochu zamotal. SLC cache sa pouziva aj mimo sekvencnych zapisov ak sa bavime o consumer SSD. Pri enterprise diskoch je to ale ine. Tam je potrebna konzistentost/predikovatelnost vykonu a SLC cache by tam robila bordel. Tam sa vykon nahana viackanalovymi radicmi.
-
Podle wiki gentoo zápis z roku 2019 bývá pages size 4-16 KB (nejmenší zapisovatelný blok dat), ale Erase blosk size (nejmenší data které je možné smazat) až 8 MiB. To se tak změnilo?
https://wiki.gentoo.org/wiki/SSD
Zmenilo sa. Velkost erase blokov rastie so zhustovanim/zvecsovnaim NAND flash. Je to vlastnost NAND. Teraz ma nenapadne ako sa to odbornejsie vola.
Tazke erase bloky postupne rastu.
Pri dnesnych SSD su erase bloky vecsie ako 8MiB.
Prosim ta napis typ toho noveho NVME SSD. Vlastne noveho aj stareho SSD.
-
Nejsem si úplně jist, jestli je to řešitelné čistě na úrovni FS. Čekám, že databáze použije fsync. A pokud by v takové situaci FS neudělal permanentní zápis, bylo by to IMHO proti specifikaci: https://www.man7.org/linux/man-pages/man2/fdatasync.2.html
Aby tehdy měl FS prostor zapisovat data se zpožděním, nesmí mu to databáze kazit fsyncem. Vypnutí fsync by zvládl zařídit nástroj s příhodným názvem eatmydata, ale to asi není to, co chcete, když požadujete konzistenci dat po výpadku. Nabízí se spíše řešit problém na úrovni samotné databáze, možná na aplikační úrovni – například zápisy zabalit do transakcí po minutě. Potom dostane DB prostor zapsat vše naráz.
Další věc, co tu už víceméně padla, je, že některé mechanismy budou DB a v ZFS duplicitně, a je otázka, jestli nejít spíš do ext4… Ale možná pro ZFS zde budete mít nějaký důvod…
-
Ač všichni výrobci zdá se bedlivě mlží co se týče velikostí page Size, Block Size a Plane Size, tak zde jsem našel specifikaci
jednoho z těch lepších dísků Western Digital RED SN700, který má stabilní výkon a životnost 2000 TBW.
specifikace: https://www.techpowerup.com/ssd-specs/western-digital-red-sn700-1-tb.d1619
Prodává se např. zde: https://www.alza.cz/wd-red-sn700-nvme-1tb-d6998050.htm
Page Size: 16 KB # nejmenší množství dat, které je možné zapsat
Block Size: 1152 Pages = 18,432 MB # nejmenší množství dat, které je možné smazat
Plane Size: 1822 Blocks
Z toho nejspíše plyne, že u těchto disků mít recordsize menší než 16KB zjevně nedává smysl.
Jestli to ale znamená čtyřnásobné nebo 32 násobné Write amplification zůstává záhadou. Protože souborový systém přece stále zapisuje po 512 Bytech, nebo 4 KBtech. Tedy jak dobře se disk brání proti zbytečnému navýšení zápisů? Zjevně nezbývá, než to otestovat pomocí DD, které dovoluje zápisovat na neformátovaný disk 512B nebo 4KB bloky. Když provedu tisíc zápisů náhodných dat, mohu pak sledovat jak se pohne opotřebení disku. A kolik bude disk hlásit, že bylo zapsáno.
Zajímavý je také údaj: SLC Write Cache: Yes
Tedy je možné, že si to nejdříve zapíše do SLC, pak si to přetřídí a minimalizuje finální zápisy. Jak se to ale projevuje na počítadlech je asi nutné vyzkoušet.
-
Tedy u zfs je optimální mít ashift 14 ? Aby to bylo těch 16 KB, a recordsize také minimálně 16 KB ?
-
Ještě jsem přemýšlel o write amplification u SLC write cache, a bude to asi složitější. Sice to znamená, že při prvním zápisu zapíšeme do násobně (3násobně u TLC) více buněk, ale zdaleka to nemusí znamenat až tolikrát (4krát u TLC) větší write amplification:
1. Dejme tomu, že do SLC se podaří zapsat na poprvé, do ostatních se bude zápis opakovat. Nemám moc představu, jak často se to děje.
2. Je otázka, jestli má vliv, že se do n-bitového MLC zapisují jednotlivé úrovně postupně. Možná ne, tuším, že vliv má počet mazání, ne počet zápisů.
-
A tady je specifikace lepšího SATA 2.5 disku.
https://www.techpowerup.com/ssd-specs/kingston-dc600m-960-gb.d2052
(https://tpucdn.com/ssd-specs/images/d/2052-front.small.jpg)
Capacity: 960 GB
Endurance:
(up to) 3000 P/E Cycles
(100000 in SLC Mode)
Endurance: 1752 TBW
Page Size: 16 KB
Block Size: 1344 Pages
Plane Size: 448 Blocks
DRAM Cache
Type: DDR4-3200 CL22
Name: NANYANT5AD512M8E3-JR
Capacity: 2048 MB
(4x 512 MB)
Organization: 4Gx8
Power Loss Protection: Yes # má tam kondenzátory, které vystačí zjevně na uložení z paměti na disk
Koupit lze zde: https://pevne-disky.heureka.cz/kingston-dc600m-enterprise-960gb-sedc600m-960g/#prehled
Je například možné, že data co se často mění má uložené jen v SLC a jinam je přesune až se to ustálí?
-
Má-li SLC cache, možná ani nepotřebuje kondenzátory…
Často měněná data jen v SLC – zajímavý nápad, dosud jsem si myslel, že se data ze SLC cache hned přeskládají. Toto by znamenalo asi komplikovanější logiku a vyžadovalo volné místo, ale přineslo by to menší WAF a rychlejší čtení některých dat.
-
Je například možné, že data co se často mění má uložené jen v SLC a jinam je přesune až se to ustálí?
Nie.
Toto je TLC SSD bez SLC cache. Takze ziadne ukladanie do SLC a potom presuvanie do TLC.
Ako som pisal pri enterprsie diskoch si nemozes dovolit pouzivat SLC cache. To by ti lietali latencie a rychlosti a to by boli nepouzitlene disky na serioznu pracu.
Ten RED SSD je consumer SSD so statickou SLC cache, starsimi NAND s menej vrstvami(kvoli vydrzi) a optimalizovanym FW pre pouzite v NAS.
-
Má-li SLC cache, možná ani nepotřebuje kondenzátory…
Potrebuje.
Kondenzatory potrebujes na zalohovanie DRAM cache aby sa data pri vpyadku napajania stihli zapisat z DRAM cache na disk.
Často měněná data jen v SLC – zajímavý nápad, dosud jsem si myslel, že se data ze SLC cache hned přeskládají. Toto by znamenalo asi komplikovanější logiku a vyžadovalo volné místo, ale přineslo by to menší WAF a rychlejší čtení některých dat.
Toto je nepochopenie zo strany xsouku04. Enterprise SSD nemaju SLC cache.
Pri consumer SSD zalezi od vyrobcu aku nastavi logiku(od firmwaru). Niektore SSD sa snazia vyprazdnit SLC cache, co najskor a ine nie. Ono aj zalezi, ci mas staticku alebo dynamicku SLC cahce.
Asi ziadne SSD nedrzi casto menene data v SLC. To nevies dobre predigovat a rozne taketo koncepty neprinasali ocakavany efekt.
Tam, kde ide o (konzistentny)vykon SLC cache nema miesto. To je dobre tak do consumer segmentu, kde ti nevadi kolisanie a mas tam medzery na vyprazdnenie SLC cache.
-
Este jedna zaujimavost ak by niekoho zaujimalo.
Pozeral som teraz na SSD Micron 7400 a tam vyrobca udava zaujimave cisla v specifikaci ohladom objemu zapisu dat, ktore vyrobcovia bezne neudavaju.
Pri nahodnom 4k zapise to pri prepocte vychadza na 1DWPD. Pri 128k sekvencnom zapise to vychadza na nieco cez 3DWPD.
https://www.simms.co.uk/PDFS/Products/SSD/micron_7400_nvme_ssd_product_brief.pdf
-
Zajímavé, jeden disk má jen 512B, druhý jen 4k a třetí (Kingston 2TB) umí oboje a teď je 512B, tak ho přepnu. Díky
Prosím, dej nějaký feedback, jestli se nějak zlepšil výkon.
Taky mám pár disků, které má asi smysl přepnout, ale bez měření není posvícení :-D
Dík!
Tak jsem přepnul 3 disky z 512B na 4kB. Zkusil jsem to měřit v jednom případě pomocí https://pibenchmarks.com, tedy
curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash
ale asi to není ideální benchmark, nebo je rozdíl malý. Pokud to pustím vícekrát, tak disperze jednotlivých výsledků je velká. Jestli máte nějaký dobrý test, který by zatěžoval řadič disku, tak sem s ním a já to zkusím.
-
Až skončí to horko, tak se do toho pustím.