Názory k článku
Linuxový souborový systém BeamFS umí sám opravovat poškozená data
-
> 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. -
> 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.
-
Michal ŠmucrStříbrný podporovatel
> 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 :)
ČLÁNKY DO MAILU