Měření životnosti NVMe disku

CPU

  • *****
  • 829
    • Zobrazit profil
    • E-mail
Re:Měření životnosti NVMe disku
« Odpověď #15 kdy: 03. 08. 2024, 16:09:43 »

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...
« Poslední změna: 03. 08. 2024, 16:15:03 od CPU »


RDa

  • *****
  • 2 674
    • Zobrazit profil
    • E-mail
Re:Měření životnosti NVMe disku
« Odpověď #16 kdy: 04. 08. 2024, 01:50:43 »
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

Re:Měření životnosti NVMe disku
« Odpověď #17 kdy: 04. 08. 2024, 10:38:20 »
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

CPU

  • *****
  • 829
    • Zobrazit profil
    • E-mail
Re:Měření životnosti NVMe disku
« Odpověď #18 kdy: 04. 08. 2024, 10:55:56 »
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!

Re:Měření životnosti NVMe disku
« Odpověď #19 kdy: 04. 08. 2024, 12:39:12 »
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.


Re:Měření životnosti NVMe disku
« Odpověď #20 kdy: 04. 08. 2024, 16:22:14 »
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 :)

CPU

  • *****
  • 829
    • Zobrazit profil
    • E-mail
Re:Měření životnosti NVMe disku
« Odpověď #21 kdy: 04. 08. 2024, 17:02:45 »
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
15% výběr vhodného FS: https://www.phoronix.com/review/linux-58-filesystems/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.
« Poslední změna: 04. 08. 2024, 17:06:03 od CPU »

Re:Měření životnosti NVMe disku
« Odpověď #22 kdy: 04. 08. 2024, 20:30:44 »
Š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ší.
« Poslední změna: 04. 08. 2024, 20:34:46 od Vít Šesták (v6ak) »

Re:Měření životnosti NVMe disku
« Odpověď #23 kdy: 04. 08. 2024, 21:30:27 »
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ší :)
« Poslední změna: 04. 08. 2024, 21:35:54 od Michal Šmucr »

Re:Měření životnosti NVMe disku
« Odpověď #24 kdy: 04. 08. 2024, 21:41:28 »
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í.

Re:Měření životnosti NVMe disku
« Odpověď #25 kdy: 04. 08. 2024, 22:50:59 »
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.

RDa

  • *****
  • 2 674
    • Zobrazit profil
    • E-mail
Re:Měření životnosti NVMe disku
« Odpověď #26 kdy: 04. 08. 2024, 23:09:18 »
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.

Re:Měření životnosti NVMe disku
« Odpověď #27 kdy: 06. 08. 2024, 10:42:04 »
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.
Citace
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.
Citace
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.
Citace
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.

RDa

  • *****
  • 2 674
    • Zobrazit profil
    • E-mail
Re:Měření životnosti NVMe disku
« Odpověď #28 kdy: 06. 08. 2024, 11:11:09 »
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.

Re:Měření životnosti NVMe disku
« Odpověď #29 kdy: 06. 08. 2024, 11:49:06 »
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.