Vlákno názorů k článku
Linuxový souborový systém BeamFS umí sám opravovat poškozená data od RDa - RS a opravy patri to blokove vrstvy, je...

RS a opravy patri to blokove vrstvy, je uplne zbytecne to delat na urovni VFS.

Neznam SSD ktere by vratilo data s preklopenym bitem - jiste, selhat muze i linka, ale v tom pripade staci re-read bez cache.

Jen kontrolní dotaz: kolik SSD vám obíhá kolem Země po oběžné dráze?

To není o oběžné dráze, ale o tom, že když to umístím do blokové vrstvy pod fs tak můžu mít zodolněný libovolný fs, stejně jako šifrovaný. Není důvod vytvářet další fs.

Tam jde spíš o to, že samotné SSD už obsahuje opravný systém. Dovolím si domnívat se, že při neopravitelném poškození dat na úrovni flash paměti, SSD oznámí vadný blok, než aby vrátil chybná data. To samé i tvrdokol.

Tomu vývojáři nula, co to tedy implikuje?

O vývojáři nemluvím. RDa prohlásil, že "nezna SSD ktere by vratilo data s preklopenym bitem". Pokud mu ale nějaká SSD nekrouží kolem Země, pak je logicky nemůž znát z prostředí, kam to je mimo jiné zamýšleno.

SSD ti nema jak vratit data s chybnym bitem. Samotne medium uz samoopravnymi kody chraneno je a preklopeni jednoho zpusobi ze oprava zafunguje.

Vubec nechapu proc se ten autor snazi svadet misto chyby na medium - kdyz vse ostatni je mnohem nachylnejsi k preklopeni bitu, protoze bud to zadne ochrany nema, nebo je ma velice slabe, resp. u vseho je spis ta kontrola - nez oprava.

Vady jsou proste transientni - v ram/bufferech/na spojeni a samotne retry postaci.

Kdyby clanek zminoval raw-nand block device jako backing reseni tak budiz, ale ne.. on tam predpoklada uplne nemysly.

Kazdej jeden disk (nejen ssd ale i mechanicky disky) uz desitky let obsahuje samoopravny kod. Opravidelne chyby cteni jsou zcela bezne a bezny disky je vubec nepousteji smerem ven. Tudiz se ti vazne nemuze nijak stat, ze bys dostal "vadny bit" a jakakoli funcionalita na to tema jen duplikuje to co uz je o nekolik urovni niz.

Tudiz to zbytecne zabira misto a zbytecne to zpomaluje praci s diskem.

Smysl by mozna a hypoteticky davalo, kdyby to dokazalo fungovat podobne jako QR = treba by to zvladlo data zrekonstruovat pri poskozeni 10, 20, 40% ... jenze to by taky znamenalo, ze to musi mit tech 40% dat navic ze?

> zbytecne to delat na urovni VFS
Ano ale uz sme si zvykle pri ZFS, BTRFS, ... ze riesia veci ktore sme zvykli riesit na 'blokovej' vrstve a ma to niektore pozitiva (miesanie diskov, zjednoduseny management, ...).
V principe ak to bude uzitocne nic nebrani rovnaku techniku pridat aj do blokovej vrstvy.

tak zfs/btrfs ma jenom checksumy, stejne jako napr. dm-integrity

ty RS/BCH me zajimaji, pac mam nemale mnozstvi raw nand flashek - a delat to v SW by bylo snadnejsi nez v HW, pak uz jenom zalezi jaky vykon clovek od toho ocekava

26. 10. 2026, 09:55 editováno autorem komentáře

No vsak tipujem ze sa to bude nastavit kolko bitov sa bude detekovat a kolko sa bude dat opravit podla toho sa bude zvacsovat ta 'kontrolno-opravna suma'.

> RS a opravy patri to blokove vrstvy, je uplne zbytecne to delat na urovni VFS.

Též mě to napadlo při čtení. A to selhání při čtení pointeru to podporuje. Nemuselo by se to řešit pro každou operaci zvlášť. Dokonce tuším, že něco na DM již existuje. Ale možná jen pro read-only.

Na druhou stranu u read-write to může být obtížné. Opravné kódy nafouknou blok. Znamená to, že:

a. Musíme pro jeden blok použít nějaké další místo. Kde ho vzít? V jiném bloku? Jak vyřešit atomicitu zápisu? Žurnálováním? Najednou ale budete mít dvě úrovně žurnálu, na FS a na blokové vrstvě. Z hlediska efektivity nic moc, a nabízí se vše umístit do FS.
b. Zmenšíme bloky. Hádám, že prakticky všechno ale bude pracovat s bloky velikosti nějaké mocniny dvou, takže leda snížit na polovinu (popř. ještě méně – čtvrtinu, osminu, …). A možná tu budou nějaké meze, kam až lze jít. IIRC se používají 512B a 4096B bloky. Lze použít něco mezi tím? A pokud mám SSD s 512B bloky a nemohu/nechci to přepnout na něco většího, mohu navenek použít 256B bloky, nebo s tak malými bloky už nikdo nepočítá? Realisticky se může stát, že to bude vyžadovat SSD s 4K bloky (na 512B to odmítne fungovat), a navenek to bude muset používat 512B bloky.

Jo, ještě by asi šlo z 4K bloku udělat 3*512B blok a zbytek použít pro opravné kódy. Akorát každý náhodný zápis 512B bloku si vyžádá čtení (možná z cache), úpravu a následný zápis 4K bloku. (U sekvenčního zápisu ten problém mizí, tuto operaci musíme potenciálně dělat jen u krajních bloků.)

doporucuji prostudovat dm-integrity - resi tam ty same otazky (a neco se resi zurnalem):

https://docs.kernel.org/admin-guide/device-mapper/dm-integrity.html

nabyl jsem z toho dojmu, ze to resi jen checksumy, ne samo-opravu

Díky. Tady jde IIUC o kontrolu, že někdo nepodhodil jiná data (byť to možná dovolí kombinovat různé verze dat), tedy ne checksumy, ale nejspíš kryptografické MAC. Ale jo, z hlediska bloků řeší podobný problém. Ano, s žurnálem, takže za cenu duplikace žurnálu => pokles efektivity.

Jiný tradeoff má dm-verity, které neumožňuje zápis, čímž nemusí tyto problémy s atomicitou vůbec řešit.

Každopádně dokud nemáme vyřešený problém s velikostí bloku (ať už FS podporující menší bloky, co nejsou mocnina dvou, nebo naopak SSD podporující větší bloky, co nejsou mocnina dvou*), dává mi nějaký smysl to řešit i na úrovni FS. Bohužel.

*) Vzhledem me kompresi apod. to nemusí být až takové sci-fi. Problém bude spíše s protokoly a s poptávkou.

> RS a opravy patri to blokove vrstvy, je uplne zbytecne to delat na urovni VFS.

Taky mi to tak přijde.
Než psát v jednom člověku vlastní filesystém se všemi náležitostmi, VFS rozhraním, orderingem, kontrolami atp. a udržovat ho, tak bych se asi spíš zaměřil na úpravu dm-integrity s přidáním automatické korekce při čtení. A použil jakýkoliv jiný vhodný, existující fs nad tím.

Kódy bych nejspíš umístil do speciální oblasti na blok. zařízení (kartě, disku) a zachoval 4KB alokační jednotky. Chápu, že to má výhody i nevýhody, ano jsou tam další latence, ano musí se to udržovat konzistentní (další žurnál nebo bitmapa).. Zas ty nezarovnané IO operace a padding už na VFS úrovni s těmi 3808 B dlouhými bloky a RMW cykly rovnou tam (mimo ostatních vrstev pod tím) mi taky nepřijdou jako úplně výhra. Každopádně to bude vždycky něco za něco a vždycky to odnese latence, write amplification nebo propustnost.

Ale zas jak tu píše Martin Poljak, co já můžu psát, když nespravuju žádné zařízení na oběžné dráze :)