Dotaz: Jak se opotřebovává SSD disk?

[Míra]

Zdravím, vím, že paměťová buňka na SSD disku se používáním opotřebovává a proto řadič ukládánání dat rozhazuje na místa, který nebyly dlouho použitý. Tím by se ty buňky měly šetřit. Jenže když se někam zapíšou data, tak se musí do nějaké FAT tabulky, nebo jiný, záznam aktualizovat. Tudíž zapisovaná data se uloží na jiný místo, ale FAT tabulka půjde časem do kopru. Tak to alespoň chápu. Neznám způsob ukládání dat u EXT4 (kterej asi používám nejvíc) ale jiný FS na tom musej bejt podobně - FAT tabulka musí trpět mnohem víc, než zbytek disku. Jak to vlastně s tím opotřebováním vypadá? A jakej je pak rozdíl v použitým file systému? Je nějakej FS optimální pro SSD?

---

---

Odpovědi

[Sten]

Interní alokační záznamy SSD používají jiný druh buněk, který zvládne řádově víc přepisů, ale je taky řádově dražší. Navíc jsou zápisy alokací optimalizované tak, že to nebývá jedna tabulka, ale cyklické buffery (či nějaká podobná logovací struktura), kde se většina změn jen zapisuje na konec a teprve až při zaplnění celého bloku změn je potřeba nějaký jiný blok vymazat.

Co se týče souborových systémů, ty o interních alokacích SSD nic neví, ale vhodným návrhem mohou firmware SSD pomoct. Nejvhodnější jsou ty, které podporují TRIM, tedy sdělují firmware SSD, které bloky jsou nevyužité, takže SSD ty bloky může využít pro wear leveling, a jsou tzv. WAFL, tedy kde lze data i metadata umístit prakticky kdekoliv na disku, díky čemuž téměř všechny blokové skupiny SSD (pozn.: SSD typicky nerealokuje bloky libovolně, ale v rámci skupiny, identifikátory bloků jsou pak kratší a tak lze víc zápisů vtěsnat do jednoho bloku alokačních záznamů) lze rotovat rovnoměrně. COW filesystémy jsou obzvlášť vhodné, protože změny nezapisují do stále stejných bloků, ale rotují po disku. Takové chování má třeba btrfs.

[lertimir]

Myslím, že chybí mnoho informací, jak interně pracují SSD s bloky dat. Sice interní alokační záznamy používají jiný druh buněk, ale to jsou buňky pro wear leveleing. Pak jsou ale standardní datové bloky disku, ale v nich má FS své alokační struktury a ty se přepisují (zapisuje se do nich) jak při vyváření a zapisování do souborů tak i při mazání souborů.

Vůbec nevíme, jestli třeba nejsou tyhle bloky vytvářeny v SSD s myšlenkou na konkrétní operační systém. Stala se mi před lety příhoda, kdy jsem měl obyč Flash disk jako systémový disk servříku a dal jsem na něj ext4 FS po čase se jednak nesmírně zpomalil a také začal vykazovat chyby. Tak jsem jej následně přeformátoval zpětně na FAT a chová se v pořádku včetně toho že kontroluji po zápisu na něj shodu dat a nebyly chyby. Předpokládám, že bloky které patří FAT se v něm zpracovávají jinak s vyšší odolností na opakovaný zápis. Bloky které patří zbytku neměly takovou odolnost a když v nich byly inode pro ext4 tak se po čase pokazily.

Podobně si dokážu lehce představit znalost v SSD disku o NTFS a jiné zpracování bloků v oblastech MFT. Obecně COW FS mají lepší teoretické vlstnosti, ale ta interní realokace to stejně všechno předělá. Před 6 lety jsem psal takovou úvahu o SSD a následně jsem i parkrát psal, jak moc mne překvapuje, že ani na akademické půdě nevznikla analýza na to jaký FS by byl optimální pro NAND chipy. Myslím tím to, že jednak si teoreticky vytvořím model jak optimálně ukládat data a pak vyrobím disk bez jakékoli mezivrstvy a na něm testuji jestli to je efektivnější než obyčejný fs a disky s wear levelingem. Ale nikdo to nedělal, nebo alespon o nikom nevím.

z hlediska FS pro SSD mě v poslední době připadá velmi zajímavý bcachefs, i když zatím to na produkci není. Nicméně to bcache funguje spolehlivě.

[Sten]

Tahle optimalizace jde udělat u flash disků, kde je FAT přes celý disk standardní formát. SSD nic takového nemají, může tam být jak víc oddílů, tak tam můžou být souborové systémy, kde alokační tabulky nejsou na pevném místě (třeba NTFS). MFT je alokované jako jakýkoliv jiný soubor a s výjimkou prvního sektoru může být libovolně po disku.

[Sten]

Ty souborové systémy přímo pro NAND paměti (MTD) existují, jsou to třeba LogFS, UBIFS, JFFS, JFFS2 či YAFFS. Nějaké výzkumy se na to i dělaly, ale obecně je to hodně závislé na konkrétní technologii, takže pro obecný OS je efektivnější tam šoupnout tu mezivrstvu, která to bude optimalizovat na míru pro tu konkrétní technologii.

[Andrej]

FAT tabulka je nesmysl z rychlého a špinavého produktu (omylem zvaného operační systém) jedné rychlé a špinavé firmy.

Wear levelling na SSD slouží právě k tomu, aby se buňky, do kterých souborový systém zapisuje častěji, postupně přesouvaly mezi fyzickými bloky a nezpůsobovaly nějaké zásadní opotřebení na jednom konkrétním bloku. Nic nového pod sluncem. Za nějakých 12 let masové komerční dostupnosti SSD jsou už wear levelling algoritmy hodně pokročilé.

Navíc se jim dá pomoct tím, že se člověk vyhne nespolehlivým a zoufale fosilně zastaralým souborovým systémům typu ext4 a použije moderní souborový systém odolný proti silent data corruption a navíc s podporou copy-on-write, což wear levelling algoritmům nakonec velmi pomáhá. Btrfs nebo ZFS je jasná volba. Pokud jde o ext4, je absurdní a nepochopitelné, proč to ještě někdo používá. Při dnešních kapacitách úložišť je silent data corruption na ext4 v podstatě kritický problém — o nedávných chybách se ztrátou dat nemluvě.

Možným řešením je taky nepoužívat SSD — předražený nespolehlivý rádoby-rychlý (do prvních 10 zapsaných TB) případ WOM (write-only memory). Když jsem si tuhle pořizoval domácí server, dal jsem si tam Btrfs RAID5 pole s 6 disky po 5 TB. Jsou to 2.5" disky a SSD se na tak kompaktní pole srovnatelné kapacity v tomhle desetiletí nezmůže. A těch 700 MB/s, které to v pohodě dává, tu a tam i GB/s, mi prostě stačí. A při 128 GB RAM mě netrápí nedostatek cache nebo úvahy, jak dlouho startuje to či ono — po pár hodinách provozu stejně bude všechno v RAM. Kdo SSD nevěří, není nijak nucený ho používat — harddisky tu budou ještě dlouho a nějaké často přepisované bloky je až tolik netankují.

[cronin]

BTRFS RAID5

[Andrej]

To je v podstatě všeho všudy FUD. Samozřejmě jsem si před sestavením toho pole přečetl všechny „děsivé“ zvěsti o tom, že „zrovna teď“ nemám používat BTRFS RAID5. Pak jsem se dočetl, že vlastně klidně jo, až na pár zbývajících okrajových případů, které se mojí konfigurace nakonec ani netýkají… A že vzhledem k docela značným časovým investicím od firem, které Btrfs používají naprosto soustavně (například Facefuck) i těch zbývajících pár chyb v RAIDu brzy zmizí. Zbývajících vlastně není to správné slovo. Nebyly tam odjakživa. Nějaká překvapení se tu a tam objeví při každém větším přepsání LUKS, LVM a/nebo VFS. A ve srovnání s desítkami kritických chyb v ext4, které v uplynulých letech doslova žraly data, je Btrfs nakonec v podstatě nejlepší volba.

Asi takhle: Zhruba od roku 2010 používám výhradně Btrfs, k naprosté spokojenosti, v nejrůznějších konfiguracích. (Ještě někde mám nějaké to ZFS, pravda.) A jízlivě, leč shovívavě se usmívám, když mé okolí láteří nad údajnou potřebou mít diskové oddíly (což je zbytečnost z minulého desetiletí) a opakovaně ztrácí data kvůli zastaralým filesystémům a silent data corruption, ale i přesto si stále myslí, že Btrfs ještě pořád není to pravé. Inu, každému, co jeho jest.

[Sten]

Ten údajný FUD je napsaný vývojáři Btrfs. Docela pochybuju, že by nevěděli, o čem píší.

Ty okrajové případy, kdy snadno může dojít ke ztrátě dat, jsou dva: výpadek proudu (write hole) a výpadek disku (vadné parity). To první, pokud k tomu dojde při zápisu metadat, klidně může smazat třeba půlku stromu. To druhé je pro RAID5 jaksi zásadní, pokud vám nevadí, že to nepřežije výpadek disku, je RAID5 jen plýtvání místem a výkonem.

Že kód pro RAID5/6 je na vyhození, prohlásili Duncan a Ronnie Sahlberg, jedni z hlavních přispěvatelů do Btrfs.

Facebook používá Btrfs RAID10. RAID5 AFAIK v produkci nepoužívá žádná velká firma, protože to už rovnou můžou použít RAID0 a dosáhnou větší spolehlivosti, alespoň se to nebude snažil počítat data z vadné parity.

Sám používám Btrfs RAID10 na velkých diskových polích od roku 2012 (předtím se nedal poškozený FS ani přimountovat ani opravit). Až jednou bude paritní RAID opravený, tak provedu rebalance (take that, ZFS!), ale teď bych RAID5 nikam kromě na pokusy nenasazoval.

[Andrej]

Připomeňme si fakta: Oba případy postihují mdraid i dmraid, a to s mnohem větší pravděpodobností. Jak write hole, tak poškození jednoho disku (například náhodným přepsáním) pošle do kytek celé RAID5 pole (protože nemá checksumy a začne se resilverovat z neplatných dat). Btrfs se svými checksumy naopak většinu takových extrémů ustojí. A i pokud ne, aspoň nebude náhodně vracet náhodná data, což je taky v jistém smyslu cenná vlastnost.

Takže ano, jsou tam nedostatky, na ZFS zatím Btrfs nemá co do spolehlivosti, ale pořád je lepší než rádoby-RAID5 od hardwarových řadičů, LVM (dmraid) nebo mdraid, protože vše uvedené má kritické problémy a nedostatky, které právě Btrfs řeší.

[Sten]

Write hole na MD RAIDu je řešené bitmapami a nezpůsobí rozbití RAIDu. MD RAID také počítá parity správně. Checksumy lze řešit Btrfs nad MD RAIDem. Je to výrazně spolehlivější než Btrfs RAID 5.

[Andrej]

Ne, není. Doporučuji zjistit si fakta.

Jednoduchý, byť extrémní test: přepsání celého jednoho disku v poli nulami. Btrfs to ustojí, zatímco rádoby-RAID (mdraid/dmraid) nikoliv a ještě u toho zničí všechna data. Ale to už jsem vysvětloval v různých vláknech asi stokrát, proč RAID funguje, jak má, pouze pokud je integrovaný do filesystému. Nechápu, co je na tom asi tak 10 let od prvních produkčních nasazení ZFS ještě někomu nejasného. :-/

[ewew]

Nerozmýšlal si, že prečo tu mrháš čas vysvetlovaním. Nevyužil by si čas opravou chýb v tvojom ospevovanom fs ?

[Andrej]

Kdyby mi některé z těch chyb překážely, třeba bych to zkusil. Žádné mi ale právě teď nepřekáží. Které to jsou, mimochodem?.

Kromě toho, zabývat se FS je většinou vhodné jako full-time práce, nikoliv jako koníček. Přece jen to vyžaduje docela značné soustředění na jeden specifický projekt.

[Jendа]

Ale to už jsem vysvětloval v různých vláknech asi stokrát, proč RAID funguje, jak má, pouze pokud je integrovaný do filesystému.

Protipříklad 1: disk se sektorem velkým 520 bajtů, kde je 512 bajtů normální blok a zbytek checksum. Výsledkem je normální blockdevice, nad kterým funguje checksumovaný RAID. Používá IBM AS/400.

Protipříklad 2: RAID6 a RAID2.

[Andrej]

Používá IBM AS/400.

Dobře, něco třeba zase používal ENIAC, :-P ale pro domácí systém na desktopovém hardwaru mi to přijde zoufale irelevantní.

Protipříklad 2: RAID6 a RAID2.

Tak tady bych čekal trochu víc abstraktního uvažování. RAID6 má ustát výpadek dvou disků. Co takhle přepsat tedy dva disky nulami? A pak to pole nechat resilverovat, samozřejmě. (Bez FS s checksumy to opravdu nedopadne dobře.)

[Sten]

Zjistit si fakta doporučuji. Disky mají sektory checksumované, takže naprostou většinu chyb zachytí a vrátí chybu čtení, se kterou si MD RAID samozřejmě poradí. Možnost silent corruption je velmi malá, obzvlášť pokud to srovnáváme proti write hole, která se projeví při každém nesyncnutém odpojení pole. (Jak jsme mohli tak dlouho přežít bez Btrfs, kdyby to tak nebylo?) Btrfs to ještě vyšperkovalo tak, že pokud jeden disk pole odpojíte (což může udělat třeba chybný kabel nebo nějaká fluktuace napětí) a po restartu to ten disk najde, použije ho tak, jak je. Včetně starých checksumů, takže na desynchronizaci ani nepřijde.

[Andrej]

Na desynchronizaci samozřejmě přijde. Klíčové slovo je transid.

Že je možnost silent data corruption, to je názor dost závislý na tom, jaká rizika jsou pro koho přijatelná. Co třeba cat /dev/zero > /dev/sde … jejda, ouha, on to nebyl ten experimentální flashdisk, nýbrž poslední disk pole, ale uživatel si toho nevšiml a pak to přerušil, protože to trvalo dlouho, a začal se zabývat něčím jiným. Jo, kdybych se s tím nesetkal a kdyby to později nesežralo celé pole, možná bych dneska věřil, že RAID5 funguje. No, příliš nefunguje. Přesněji, nefunguje tak dobře, jak může fungovat v součinnosti se ZFS nebo Btrfs.

I takhle^^^ může vzniknout silent data corruption. Třeba se shodou šťastných náhod během celého zbytku uptime nic zásadního nestane. Proto silent. Pozdější odhalení tohoto problému způsobí u starého RAIDu něco jako apokalypsu, zatímco u Btrfs a ZFS půjde všeho všudy o drobnou nepříjemnost a veselou historku na pozdější chlastanici.

Že mají disky checksumy, to přece neznamená až tolik. Je obrovská spousta jiných možných příčin poškození dat než špatné přečtení nebo špatný zápis. (Jak dobře chrání checksumy levné disky před špatným zápisem, mimochodem?)

[Sten]

Tohle není silent data corruption a s MD RAIDem se řeší velmi snadno:

mdadm --fail /dev/mdX /dev/sdeX

Riziko silent data corruption dnes začíná (dle studií NEC) někde kolem 1 chyby na petabajt, než se dostaneme ke stoterabajtovým diskům, kde by už začalo jít o vážné riziko např. v porovnání s data corruption v ne-ECC RAM, pravděpodobně bude ještě o řád či dva nižší, jako kleslo riziko URE, když gigabajtové disky nahradily terabajtové. Pomalu to začíná být reálné, proto se ty filesystémy objevují, ale je to stále řádově méně pravděpodobné, než problémy s desynchronizací RAIDu, které Btrfs má a jsou dobře zdokumentované.

[Sten]

o řád či dva nižší

Jde o binární řád či dva (na polovinu až čtvrtinu), URE se uvádí v pravděpodobnosti 2⁻ⁿ.

[vandrovnik]

On to asi myslel tak, že uživatel si kus toho /dev/sde přepíše, ale neuvědomí si, co vlastně spáchal, a tak ten přepsaný disk z /dev/mdx nevyhodí.

[Sten]

OK, proti tomu to pomůže, ale je to tak nějak vedlejší efekt, kdy root z těch mnoha možností, kterými může data zlikvidovat, použije zrovna tu, kterou to zachytí, protože je podobná HW poruše, před kterou se to snaží chránit.

[Sten]

A co se týče transid, to tam sice je, ale je to špatně implementované, takže to v mnoha případech vypíše do dmesg:

parent transid verify failed on XXX wanted YYY found ZZZ
Ignoring transid failure

a ten disk připojí, jako kdyby žádný problém nebyl

[Sten]

Ale tak alespoň je tam tohle místo dřívějšího BUG(), který pokaždé sestřelil jádro, když se RAID desynchronizoval. To se opravovalo ještě hůř.

[pavlix]

A ve srovnání s desítkami kritických chyb v ext4, které v uplynulých letech doslova žraly data

Třeba?

[Andrej]

Ale no tak. Opravdu je tak těžké hledat?

[Jendа]

A ve srovnání s desítkami kritických chyb v ext4, které v uplynulých letech doslova žraly data

FYI btrfs používám od 3.19, o data jsem dvakrát přišel totálně (tohle a btrfsck smazal všechny adresáře a pak to při mountu řeklo failed to read chunk root on xxx, open_ctree failed) a narazil jsem na čtyři bugy dost nabourávající provoz (race condition vracející I/O error aniž by to cokoli zalogovalo, FS ve stavu po rebootu vždy vyžadujícím zero-log, mountování trvající minutu, nevypnutelný autodefrag (opraveno kolem 4.4)), Podotýkám, že ve všech šesti případech scrub proběhl bez jediné chyby. Na to, že jsem btrfs měl vlastně na čtyřech strojích (oproti desítkám strojů s ext3/4), je to docela výkon.

[Andrej]

Ano, zero-log jsem zažil jednou v roce 2010 a jednou v roce 2012, kdy šlo o nekompatibilitu v synchronizaci mezi Btrfs a vrstvami pod ním, které tenkrát byly mdraid (protože Btrfs tehdy neměl RAID5) a LUKS. Ale že bych tohle Btrfs nějak extrémně vyčítal, to se říct nedá.

O data jsem nikdy nepřišel. Naopak jsem měl s nefunkčními (nevhodnými pro 21. století) FS typu Ext4 chronický problém s poškozenými soubory. Asi tak třikrát do roka prostě přestal fungovat nějaký program (segfault, apokalypsa) a jeho reinstalace to zázračně opravila. Od nasazení Btrfs mám přesně nula takových problémů. Když mám poškozený soubor (což se mi asi třikrát stalo), vím rovnou přesně který to je. Smazat, přeinstalovat balíček, život jde dál. FS mi nevrací náhodná neplatná data. A toho si zkrátka cením.

[pc2005]

Asi tak třikrát do roka prostě přestal fungovat nějaký program (segfault, apokalypsa) a jeho reinstalace to zázračně opravila.

To jsem měl taky na slackware. Kvůli nějaké chybě závislostí při dist-upgrade se musely dva balíčky instalovat ve správně sekvenci jinak nefungoval textový editor. Jinak v instalátoru slackware 14.2 je btrfs jako experimentální a má tu vlastnost že se na něj nedá ten slackware nedá nainstalovat .

Na jednom embedded zapomínal MMC/SD řadič posílat buffery na kartu, ext2 to permanentně rozbíjelo, ext4 byl relativně OK.

[Heron]

By mě zajímalo, co s tím děláš. Mám jeden fs kontinuálně od 2011, už zažil lecos (konvert single - mirror; mirror - raid10; raid10-mirror), desítky tisích snapshotů současně, hromadu receive ze zálohy apod. Různé hrátky s rebalance, hromada rekomprimací a pořád šlape jako hodinky. Na tom fs budou datové bloky snad všech typů, které btrfs od začátku podporuje (krom raid56, s tím si nehraju).

Jedinou ztrátu dat jsem zažil vinou řadiče, kdy na jednom btrfs nad mdadm raid 10 vypadla "špatná" polovina disků nikoliv naráz, ale několik sekund po sobě a řadič ještě na některé z nich projistotu něco zapsal. mdadm se z toho nevzpamatoval, tak jsem mu pomohl s force a btrfs, sice za hlasitého křiku recovery error do logu, ty soubory dokázal poskytnout (mount -o ro). Porovnání se zálohou, žádný soubor neměl změněný obsah.

Neříkám, že ty chyby neexistují, ale někdy by mě zajímalo, co s tím děláte.

[Jendа]

By mě zajímalo, co s tím děláš.

Mě taky.

1. Server (s ECC), vytvořen BTRFS RAID1 přes dva disky (úplně standardní cestou podle btrfs wiki), po půl roce to občas začalo hlásit při přístupu k dovecot.index.log v různých maildirech I/O error. V dmesg nic, rebootem se to spravilo a za měsíc znova. Scrub s 0 chybami.
2. Notebook (bez ECC, ale memtest v pořádku). Jednou na rotačním disku, jednou na SSD, po roce používání to řeklo corrupt leaf při přístupu k pár souborům v /usr/share/něco. Scrub před rebootem i po rebootu bez jediné chyby. btrfsck začal mazat všechny adresáře, po killnutí FS nešel připojit.
3. Desktop (bez ECC, ale memtest v pořádku), 6TB FS na MD RAID 6. Po ztrátě napájení v polovině běžícího umountu příští pokus o mount selhal s tím, že FS má 11 TB, ale blokové zařízení jen 6 TB. zero-log to opravil. A po dalším rebootu (tentokrát už s korektním umountem) znovu totéž a zase to zero-log opravil.
4. Dva další desktopy: už dva roky bez jediného problému.

Server a notebook jsem předělal na ext4, na desktopu jsem upgradoval z 4.7 na 4.9 a vyrobil nový FS a uvidíme.

[ika]

Lol. Taky názor, nu což.

Náš administrátor shledal tento komentář závadným.

trolling

Zobrazit komentář

[j]

Tj ... tady mas to nevzmozeni se https://www.cnews.cz/seagate-predvadi-ssd-s-kapacitou-60-tb-disk-se-1280-cipy-nand-bude-pristi-rok/ jedna 3,5" vec.

Jestli neco do konce tohodle desetileti umre, tak to sou rotacni disky.

[Andrej]

Láryfáry. Já jsem celé své diskové pole pořídil (prosinec 2016) za cenu pod 1400 CHF. Pětkrát menší pole sestavené z SSD by mě bývalo stálo 4500 CHF, dvaapůlkrát menší pole z SSD jsem mohl mít za 7500 CHF. To se mi ovšem trochu nezdálo, mírně řečeno, ve srovnání s cenami pevných disků.

Rotační disky umřou, jakmile budou SSD za srovnatelnou cenu (což dnes nebude) a stejně spolehlivá (což nebude ani zítra). No, takže možná pozítří, že jo.

[Jendа]

Já jsem celé své diskové pole pořídil (prosinec 2016) za cenu pod 1400 CHF. Pětkrát menší pole sestavené z SSD by mě bývalo stálo 4500 CHF

Asi tě to překvapí, ale pro některá použití se kromě kapacity uvažuje třeba i o rychlosti. Z pole čtyř 5 let starých desktopových SSDček jsem vyrazil 160 kIO/s. Kolik že dá to tvoje pole rotačních disků?

[Andrej]

Nevím. Nevím, protože mě to nezajímá a připadá mi to naprosto nepodstatné při naprosté většině mých domácích use casů.

Ano, v práci máme třeba workloady, de kIO/s opravdu hraje naprosto zásadní roli a harddisky by se tam vůbec nehodily. Ale na mém domácím stroji nic takového není. Pokud mi někdy na kIO/s začne záležet, rozhodně si pořídím pár SSD. Nic proti nim nemám. Klidně můžou selhat, protože na nich budu mít dobrý FS, který se se selháním dokáže korektně vypořádat.

[pavlix]

Na mém „domácím“ využití třeba v laptopu, kde mám teď dočasně HDD místo SSD, protože jsem byl líný to řešit, mě HDD nepříjemě zdržuje a ještě obtěžuje tím, že je slyšet. :D

[Andrej]

Pak se zdá, že pro některého uživatele a některé využití je lepší SSD. (Nikde netvrdím opak.)

[MadCatX]

Chápu správně, že místo léty prověřeného Ext4, který funguje dost možná na desítkách milionů produkčních systémů jsi nasadil něco, co je broken by design?

[Andrej]

Léty prověřený Ext4. No jasně. Léta ukázala mnohé. Ext4 už léta ukazuje, proč zastaralé filesystémy nezapadají do tohoto desetiletí.

Asi by stálo za to zamyslet se nad významem sousloví broken by design. Ext4 je broken by design, stejně jako každý filesystém, který nemá vestavěné checksumy, který neumí replikovat data i metadata podle gusta (i v rámci jednoho média) a který nedovede předcházet silent data corruption — jinými slovy, klidně přečte nesmysly a nehne ani brvou.

Nejrůznějších osobních názorů v mailing listech, že Btrfs | ZFS <ten či onen FS> je broken by design, se objevilo už asi tak dvacet, ale žádný se příliš neujal.

Já nepoužívám Btrfs místo Ext4. Ext4 je prostě chybné řešení z minulého desetiletí, které zaspalo dobu a do současného desetiletí nepatří. Používal jsem Reiser4, který byl sice nejrychlejším filesystémem všech dob, ale ve chvíli, kdy začlenění do kernelu zmizelo v nedohlednu a patche přestaly být udržované (2010), nastal čas poohlédnout se po novějším řešení, které odpovídá současným požadavkům a diskovým kapacitám. Řešením byl pochopitelně ZFS a později Btrfs. Proč někdo používá paskvily bez checksumů a bez redundance, tomu vůbec nerozumím. Zkrátka nemám tak silnou zálibu v adrenalinu.

[MadCatX]

Aha. Takže jedna chyba izolovaná v jádře řady 4.0 značí, že Ext4 je paskvil, zatímco velmi zábavné bugy v Btrfs (např. https://www.spinics.net/lists/linux-btrfs/msg60903.html) nebo ten RAID56 režim, který se bude muset zgruntu předělat demonstrují, jak skvěle je Btrfs navržený a implementovaný. ZFS je trochu jiná liga, do mainline Linuxu se ale bohužel nikdy nedostane. Moderně koncipované souborové systémy jsou určitě skvělé, nicméně na Linuxu zatím nativně neexistuje takový, který by byl v produkčně použitelném stavu.

Náš administrátor shledal tento komentář závadným.

trolling

Zobrazit komentář

[Andrej]

ZFS na Linuxu přímo nativně existuje, je to prověřený „produkční“ FS a dá se používat. Ano, mít zfs a spl překládané zvlášť kvůli CDDL je voser, ale nic nebrání distribucím mít je jako balíčky.

Pokud jde o Btrfs, že by se snad všichni tihle uživatelé mýlili? To asi ne. Prostě vyhodnotili, že jim přináší nějakou zásadní přidanou hodnotu, a nasadili ho. RAID5 a RAID6 v Btrfs možná není zrovna vyspělá a „produkčně“ nasaditelná technologie a RAIDZ3 ani vyšší redundance zatím Btrfs neumí, ale to je spíš otázka času.

A ten čas bude tím kratší, čím méně FUDu kolem Btrfs bude. Tak je to ostatně s každou novou technologií.

[trekker.dk]

Léty prověřený Ext4. No jasně.

Dobrá, tak jste odkázal jednu "chybu filesystému", kde ve skutečnosti byly na vině chybné aplikace očekávající něco, co dle standardu očekávat neměly a nemohly. Filesystém se choval zcela korektně.

Nějaká reálná chyba by nebyla, což?

[Andrej]

Ale byla, samozřejmě, roztrhl se s nimi pytel v letech 2012 a 2015, což byly tak vážné incidenty, že trochu zastínily ty ostatní menší. Jak už jsem psal výše, představa, že Ext4 je „spolehlivější“ než Btrfs, je scestná. Ext4 (stejně jako všechny FS bez checksumů, replikace (meta)dat a CoW) je flawed by design a nepodpovídá dnešním kapacitám úložišť a požadavkům na spolehlivost. Nic složitějšího aní reálnějšího bych v tom nehledal.

[trekker.dk]

Ano, v pořádku, to je reálná chyba, a je tak závažná, že - přestože s jistotou existovala nejmíň rok - na ni narazil jenom málokdo.

Co takhle nějakou chybu, kvůli které ext4 ztratil všechna data? Abychom se vyrovnali tomu, co výše popsal Jenda.

[Andrej]

Anekdoty o ztrátě dat existují asi tak pro všechny filesystémy, tedy pochopitelně i pro Btrfs.

Někteří Btrfs mají za zlé, že místo aby vracel náhodné nesmysly a o něco se pokoušel třeba nad vadným diskem nebo nad chybně a náhodně přepsaným diskem, prostě rovnou řekne, že to nejde.

Nevím o tom, že by Btrfs kdy měl průser srovnatelný se „slavnými“ Ext4 chybami. (Teď nemluvím o nějaké jednotlivé situaci / anekdotě, ale o celkových dopadech.)

[trekker.dk]

Což bude trochu zaujatostí, protože chyba způsobující ztrátu všech dat je "slavnější" než cokoliv, co jste tady proti Ext4 odkázal. Včetně nějakých blíže nespecifikovaných "dopadů"

[Andrej]

Tak už to bývá, že když mi nějaký software dlouho spolehlivě slouží, chtě nechtě jsem trochu zaujatý v jeho prospěch.

[trekker.dk]

Fajn, potom ovšem svoje subjektivní názory neprezentujte jako objektivní fakta.

[pavlix]

Dobrá, tak jste odkázal jednu "chybu filesystému", kde ve skutečnosti byly na vině chybné aplikace očekávající něco, co dle standardu očekávat neměly a nemohly.

Epic fail.

[Sten]

Broken by design je kód pro RAID5/6, ne Btrfs jako celek. RAID10 funguje velmi dobře a spolehlivě už několik let.

[pavlix]

Když chci držet data a nechci se bát o pád více disků, tak chci asi RAID6 a ne RAID 10.

[Sten]

Tak použijete MD RAID, úplně stejně jako u ext4. Btrfs má i tam výhodu, že dokáže detekovat silent corruption, podporuje snapshoty a výpadek proudu nedostane data do nekonzistentního stavu (u ext4 jen za cenu výrazného poklesu výkonu pomocí journal=data).

[trekker.dk]

On MD RAID nerespektuje požadavky na flush dat na disk? To by mělo nekonzistenci zabránit, ne?

[Sten]

Respektuje, ale žurnál ve výchozím nastavení brání jen nekonzistenci metadat, ne dat.

[trekker.dk]

No dobře, ale kde vznikne ten nekonzistentní stav? Zapíšu data, zavolám sync, data se zapíší na všechny disky, sync se vrátí, data jsou zapsaná a konzistentní.

Nebo tím bylo myšleno to, když přepíšu existující data, že jakmile filesystém začne dělat writeback, tak stará data už nemám, ale nová ještě zapsaná nejsou?

[Andrej]

Mnohem větší problém než write hole všeho druhu je silent data corruption. Zapíšu, zavolám sync, všechno je v pořádku, ale příště odtamtud prostě přečtu něco jiného. Takový problém donedávna (10 let zpátky, řekněme) zdánlivě neexistoval. Jenže dnešní disky jsou nesrovnatelně větší a jejich odolnost vůči silent data corruption není valná, zejména poté, co nekorektní triky s předstíráním sync začaly být naprosto běžné i u dražších disků v RAED polích (což je ošklivá parafráze, ale leckdy odpovídá realitě lépe než RAID). Kromě toho, poškození dat rozhodně nemusí vznikat jenom kvůli disku. Dokonce ani nemusí být záležitostí hardwaru. Náhodné změny může způsobit vadný řadič, vadný kabel, vadná cache disku, vadná RAM (bez ECC) nebo klidně taky bug v kernelu. Pro všechny takové případy se hodí checksumy a redundance na úrovni filesystému.

[Sten]

Vadný kabel nemůže způsobit náhodné změny. Data přenášená přes kabel jsou checksumovaná.

Jak ochrání checksumy před vadnou RAM? Vždyť jsou počítané v RAM.

Bug v kernelu může úplně stejně způsobit zápis vadných checksumů, takže data budete naopak ztrácet. Třeba jako se to teď stává u RAID5.

[Kate]

Počítané v RAM možná jsou, ale sedět asi nebudou :) Resp. myslíš že se to bude počítat pokaždé ve stejném bloku paměti se stejnou chybou?

[Jendа]

Pouze pokud k chybě dojde mezi spočítáním checksumu a vyčtením přes DMA řadičem. Jenže předtím se s těmi daty asi něco užitečného dělalo, pak se musela zkopírovat do kernelu atd., takže šance, že náhodná chyba spadne právě do toho dobrého okamžiku, je docela malá.

[Sten]

Problém nastane, pokud vypadne proud mezi zápisem dat a syncem. Některá data budou zapsaná, jiná ne. Metadata jsou proti tomu chráněna žurnálem, ale data normálně ne. Chránit je lze, ale stojí to dost výkonu. Btrfs drží konzistentní oboje díky COW.

[trekker.dk]

Problém nastane, pokud vypadne proud mezi zápisem dat a syncem.

Jo, jasně, to je v pořádku - dokud se mi nevrátil sync, data nejsou zapsaná vůbec (a to, co už se zapsalo, toho si nevšímám.)

[Sten]

To ale právě není řešené bez žurnálování dat, kde si FS zapisuje, kterých dat si všímat má a kterých ještě ne. Aplikace to typicky řeší tak, že zapisují do dočasného souboru a data commitují pomocí rename (mv), ale to je workaround a ne všechny aplikace to dělají.

[Andrej]

Pak je to jenom otázka času. Btrfs prostě někdo opraví. Tedy, těch několik okrajových případů, u kterých by se uživatel musel hodně snažit, aby je potkal.

Případně je tu ZFS, který má nejen RAID6, ale i vyšší stupně redundance, třeba toleranci selhání 3 disků z N.

[Andrej]

Tolik asi k té otázce času.

[Jendа]

RAID10 funguje velmi dobře a spolehlivě už několik let.

Mně se to tak dlouho náhodně rozesíralo, až jsem to z produkce vykopal a teď to používám jenom na zálohy (kde jsem nic lepšího nevymyslel kvůli snapshotům) (máme dva stroje na zálohy a doufám, že se to nerozbije na obou současně). A když se to teď rozbilo, tak jsem spustil mkfs.btrfs a zálohy rsyncuju znova.

[Sten]

Není to náhodou RHEL nebo CentOS? RAID10 vyžaduje pro spolehlivý běh jádro 3.17+ (lépe 4.2+), to je už několik let staré, ale RHEL/CentOS stále běží na 3.10.

[Jendа]

Debian, ovšem jádro (a pak i btrfs-tools) z backportů.

[Andrej]

Aha. To vysvětluje mnohé.

32768 klíčů v OpenSSL bylo tenkrát kdysi taky trochu backport.

[trekker.dk]

Měl byste i něco k věci? Třeba nějakou ukázku toho, že by jádro v Debianu obsahovalo oproti upstreamu nějakou úpravu btrfs, která něco rozbila? (Zatímco v čistém upstreamu to fungovalo.)

[Andrej]

Zastaralé jádro může být v případě Btrfs dost zásadní problém. Hlavně pokud jde o nejnovější opravy. Problém tedy není, co jádro Debianu obsahuje, nýbrž co neobsahuje.

[Jendа]

Přečetl sis z mého komentáře víc než první slovo?

[Sten]

V backportech je jádro 4.9

[antifluslshitbuzerant]

Špinavá firma andrej?Mám SSD Toshiba 112 GB cca 7 let a je pořád rychlej a s plnou kapacitou.Používám ho denně cca 6 hodin >8~DDD

[Andrej]

Ještě někdo se ptá, proč zakázat anonymy na ABCLinuxu? Tady^^^ je důvod číslo 574 z tisíce.

[Leten]

(_!_) oIo < i > !

[Antiandrej]

Jo zakaž je vlastenče & pak tady nebude už vůbec nikdo.Jo & pozdravuj in memoriam,v Curychu ,,vlastence'' Karla Kryla >8~#D

[Míra]

No, já si to představuju tak, že když se mi třeba často ukládá nějaký konfigurační soubor, tak se moc neopotřebovává místo, kde jsou data, protože jich není moc a asi se pokaždé zapíšou jinam. Ale opotřebovává se místo, kde je záznam o umístění toho souboru a jeho atributy. Kdyby třeba nějakej program opakovaně přepisoval atributy jednoho souboru, tak za chvíli vypálí jedno místo? Ale možná se pletu...

[aceman]

Ale aj to miesto ukladajuce atributy suboru si disk interne presuva. Cize aj spominana FAT tabulka je logicky (cislo sektoru z pohladu OS) stale povedzme na zaciatku disku, ale firmware disku ju potichu presuva do roznych fyzickych miest (pamatovych buniek), aby nedoslo k opotrebeniu fyzickej bunky (nie logickej).

[pc2005]

Ještě nezapomeňte že SSD disky periodicky kontrolujou stav zapsaných dat (protože ty buňky se po čase vybíjejí) a v případě kritického množství náboje tu hodnotu přepíšou. To byla taky první z chyb Samsung EVO (moc časté přepisování), jejíž oprava pak zase potichu ničila data při tom NCQ TRIMu.

[Michal]

Tazatel si podle dotazu i podle reakcí na komentáře myslí, že SSD při opakovaném požadavku na zápis do sektoru čídslo X zapíše data pokaždé do stejného fyzického bloku. Což není pravda. Řadič má vlastní, na operačním systému a souborovém systému zcela nezávislý, mechanismus, kterým wear leveling řeší. OS do něho (naštěstí!) nemůže nijak zasahovat, může jen dávat hinty v podobě TRIM příkazů.

Kdyby SSD spoléhal na to, že wear leveling vyřeší OS, byl by to naprosto nepoužitelný kus hardware.

[trekker.dk]

V tom disku wear levelling zajišťuje software. Operační systém je co? Software. Když disky budou poskytovat přímý přístup k úložným blokům bez mezivrstev, buďte si jistý, že do Linuxu někdo dopíše podporu pro wear levelling. (Dokonce mám pocit, že už se stalo.)

[pavlix]

Linux, pokud vím, podporuje specializované wear leveling filesystémy, když na to přijde.

[pavlix]

A emulaci block device nad flash pomocí wear leveling tuším umí taky.

[Michal]

No jistě, výrobci disku mohou dát přístup přímo k blokům. Ale za jedné podmínky - při použití této funkce okamžitě přicházíte o záruku. Takže ve výsledku ne, ve spotřebitelské sféře nikdy nic takového udělat nemůžou.

[Filip Jirsák]

Nemůžete přijít o záruku z rozhodnutí výrobce, záruka je daná zákonem. Navíc by to bylo úplně zbytečné, protože záruka se nevztahuje na běžné opotřebení způsobené používáním.

[pavlix]

Jedna věc je suše právní pohled, jedna věc je každodenní realita. Já osobně řeším záruky přes DAS a lehce se stane, že ani DAS nepovažuje záruku za výrobek za pár tisíc za dostatečně zajímavou, aby šla do sporu, takže nabídne částku ve výši pohledávky a tím to pro ně končí. Akorát se obávám, že budou mít trochu jiné ceny pro firmy než pro domácnosti.

[Jendа]

OS do něho (naštěstí!) nemůže nijak zasahovat

Kdyby SSD spoléhal na to, že wear leveling vyřeší OS, byl by to naprosto nepoužitelný kus hardware.

Já si naopak myslím, že kdyby se to nechalo na OS, bylo by to lepší - protože OS má víc informací (tady je soubor, tady jsou metadata, …), na rozdíl od TRIMu tak může dělat wear levelling s lepší granularitou.

Ostatně v Linuxu už to dávno je, JFFS2 a několik novějších alternativ.

[alkoholik]

Jenze OS nezna historii toho disku. Treba, ze je na nem uz paty fs..

[pc2005]

To by šlo exportovat přes SMART.

[alkoholik]

Pocet zapisu v kazde bunce? To je ale odvazna myslenka! Kor, kdyz tuhle informaci otrebujes pri uplne kazdem zapisu..

[pavlix]

Každopádně pokud by to řešit nešlo, neřešil by to ten software v SSD. :)

[Jendа]

Asi šlo o to, že by se ty informace o všech buňkách tahaly přes SMART - který tipuju na větší data nebude úplně nejrychlejší.

[pc2005]

Tak není technický problém udělat inverzní TRIM command, kde bude naopak disk radit OS.

[pc2005]

OS si může tu bitmapu/čítače nacacheovat při každém startu (asi jako každý normální OS si nacacheuje FAT).

[alkoholik]

Dnes se bezne pouzivaji 4KB bloky a zivotnost je v radu stovek az tisicu prepisu, takze ti nebude stacit jeden byte. Vyrobci RAM by z tebe meli radost.

[pc2005]

Mám za to že NAND flashe maj víc než 1MiB bloky. Myslím, že jsme se o tom v jedné diskuzi tady na abclinuxu nedávno s někým bavili.

[pc2005]

+ i kdyby to mělo 4kB bloky, tak by měl stejný problém řadič toho NAND čipu.

[alkoholik]

To jsou erase bloky. Ty to musis resit s vetsi granularitou. Co bydes delat, kdyz se ti milionkrat prepise atime v inode pro /?

[pc2005]

To co bude dělat realtime OS na tom SSD .

Můj počítač má větší výkon a víc RAM než ten SoC na SSD. Teď jen z toho SSD dostat interface, co mě dá přístup k fyzickým blokům a pohoda.

[Sten]

OS neví, jak konkrétně se chová typ buněk v tom disku. Může mu to říct uživatel, ale to není něco, co by zvládla většina uživatelů. SSD má výhodu, že je to standardní SATA. JFFS se používá tam, kde je systém připravený od výrobce.

[lertimir]

To je o čem jsem psal výš. To že je to standardní SATA je výhoda i nevýhoda. výhoda v tom, že nemusíš nic dělat v OS, nevýhoda proto, že použivají systémy určené rpo rotační disky. Standardní staré návrhy FS mají zabudovánu optimalizaci pro rotační disky. Když bys navrhoval FS někdy v roce 1980-2000 tak si to ani nepředstaví jinak. A sekvenční operace s daty budeš silně prioritzovat před náhodnými sektory na disku, díky tomu že víš jak ti vše zpomalí seek time, ale opětovné přepisování jediného bloku nebudeš řečit vůbec. Budeš takové priority mít v pozadí v hlavě a při návrhu s tím budeš pořád pracovat. A takové jsou současné systému. Problém lepšího přístupu k SSD je v tom jak jsi napsal:

OS neví, jak konkrétně se chová typ buněk v tom disku.

Když by disk měl dva režimy. jeden kdy se chová jako standardní SATA. A druhý, kdy na stejném SATA pojede jiný set příkazů (pro SSD operace) kdy se OS může zeptat na všechny potřebné informace k konstrukci SSD ako jsou velikosti bloku na čtení zásip mazáni. časové délky těchto operaci, a možná ještě další informace, tak bude na čem pracovat. Když si vezmeš, tak to jak postavit FS máme důležité implementace alespoň Ext4, XFS, JFS a asi i nevyvíjené FS od Reisera. (nemluvě z ZFS a btrfs) Každý v podstatě vyjadřuje trochu jiný názor, jak uspořádat infomrace (a metainformace) na rotačním disku tak, abychom dostali dobrý FS.

Pro SSD nic takového nemáme. Díky tomu, že SSD neposkytne informace, jak to má uvnitř, ani na tom nemůže nikdo pracovat. A všichni jsme závislí na kvalitě optimalizace, který si vymyslí výrobce SSD a řadiče a pokud je tam chyba tak to vlastně nikdo nenajde.

[Sten]

Ty systémy pro rotační disky často mají optimalizace i pro SSD, včetně jmenovaných ext4 a btrfs. A zrovna btrfs a ZFS (a obecně jakékoliv COW systémy) fungují mnohem líp na SSD než rotačním disku kvůli tomu, jak moc COW fragmentuje a jak neustále rotuje bloky.

[lertimir]

Jasně btrfs optimalizace pro SSD má (a sám také btrfs používám na všech SSD se kterými pracuji), ale to je jiná optimalizace. Pořád je disk lineární blokové zařízení se stejnými bloky a OS fakticky vůbec neví kam se to bude psát. Jenom si udělá nějaké odhady, jak data do SSD psát, aby s nimi po interní průchodu řadičem to dopadlo lépe než jinde. Vůbec operace nejsou optimalizovány podle struktury a časování čtecích, zápisových a mazacích bloků. Navíc pořád je třeba mít na mysli, že obrovské množství disků (řekl bych většina) jede NTFS a ne linuxové filové systémy a tomu musí přizpůsobit optimalizaci interních algoritmů výrobci disků. Třeba dokážu si představit, pokud by disk měl i různé typy NAND chipů (a korektně je reportoval OS), tak návrh FS, který metadata FS ukládá do málokapacitních rychlých buněk s mnoha přepisy a standardní data do velkokapacitních buněk s málo přepisy. (ale design FS nedělám a tak jsou toto jen takové jednoduché nápady, které samozřejmě mohou mít nedostatky, ale podstatné je že dokud výrobci nebudou poskytovat reálná data o tom jaké interní vlastnosti má disk tak se s tím nendá nic dělat. (třeba by to mohlo být možné jako kdysi v době PATA se propojkou nadefinovalo Master/Slave tak propojkou definovat standardní blokové SATA a nebo plnou informaci o NAND a vyřazení interního řadiče.)

[lertimir]

Já už to nechci moc rozpitvávat, ale podle mne problém je někde hluboce v základu návrhu. Na záčátku dráhy, jako mladý kluk jsem na MFF ještě pracoval s páskovými jednotkami. Podívej se na příkazy pro mt. I s diskem můžeš pracovat jako "s velmi rychlou páskovou jednotkou" a lebedit si jak rychle ti fungují příkazy fsf, bsf, seek, rewind. A to že s disky můžeme pracovat efektivněji je dané rozvojem různých FS počínaje třeba prastarým BDAM z IBM OS/360. A podle mne SSD (a NVMe) jsou také zařízení s zcela jinou fyzikální strukturou záznamu a vlastnostmi než rotační disky, a v současnoti s nimi pracujeme podobně neohrabaně, jako bychom s disky pracovali přes příkazy pro magnetickou pásku a nebo jaká byly v 60 letech minulého století práce s prvními rotačními disky prvními filovými systémy.

[pc2005]

Jj takovej NAND blok připojenej bit po bitu do počítače, to by byla lahoda .

BTW se šindelovým diskem se pracuje podobně jako s páskovou mechanikou.

[Michal]

Nikdy bych nesvěřil přístup k fíčuře, která může disk snadno odrovnat někomu, kdo neposkytuje záruku k tomu hardwaru. Hardware, který se nechá zničit softwarově si nic jiného nezaslouží.

[Míra]

Takže když si uživatel spustí něco jako toto:

touch znicit
opakuj stale {
chmod 000 znicit
chmod 777 znicit
}

tak se vlastně nic neděje?

[pc2005]

Ty změněné atributy se budou zapisovat nejdřív do diskového bufferu linuxu (free, buff/cache). Podle nastavení commit hodnoty v /etc/fstab (nebo default 30 sekund) se to pošle do diskové cache (DRAM na HDD/SSD) a i tam se to teoreticky může přepisovat (a fyzicky na médium nezapsat) a až po nějakém cooldownu těch dat v diskové cache se to zapíše fyzicky na disk.

Pokud bys to natvrdo syncovat přímo pro zápis na médium tak by změna atributů měla být podobná jako změna krátkého souboru (z pohledu klasického disku to jsou stejná data).

[xxxs]

tiez prave riesim ssd. aky teda fs, ake parametre mountu? tmpfs? swapoff? desktop, lin, asi ubuntu, i5, 8GB ram, bezny uzivatel - dochodkyna.

[cronin]

Ext4, "rw,relatime,data=ordered", s času na čas spúšťať fstrim.

[Peter Golis]

Ubuntu si už zopár rokov vie overiť že sa ide nainštalovať na SSD, a tak si nastaví optimálne hodnoty počas východzej inštalácie.

PS: CPU i5, 8G RAM, SSD v desktope pre dôchodkyňu. Vedel by si potom neskôr povedať na koľko percent dokáže bežná dôchodkyňa vyťažiť taký stroj? Môj skromný odhad je že sa dostane nad 10% len keď sa jej budú občas aplikovať záplaty systému.

[Kate]

A nezáleží tady spíš na konkrétní důchodkyni? Znám jeden pár důchodců, co na stará kolena paří 3D akce na deathmatch.

[xxxs]

ked kupujem stroje tak na 5 a viac rokov.

[R]

Otvori si tam v chromom browseri youtube, gmail a facebook a cely vykon je v hajzli.