Měření životnosti NVMe disku

[xsouku04]

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í.

[Reklama]

[Jan Fikar]

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.

[Vít Šesták (v6ak)]

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…

[CPU]

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

[Vít Šesták (v6ak)]

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.

[Reklama]

[Jan Fikar]

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

[RDa]

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.

[Vít Šesták (v6ak)]

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…

[Václav Ovsik]

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.

[RDa]

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.

[CPU]

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...

[CPU]

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é!

[Václav Ovsik]

...
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.

[Michal Šmucr]

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é.

[Michal Šmucr]

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á.