Második interjú Eduard Shishkinnel, a Reiser4 FS fejlesztőjével

Megjelent a második interjú Eduard Shishkinnel, a Reiser4 fájlrendszer fejlesztőjével.

Kezdésként emlékeztesse olvasóit, hogy hol és kinek dolgozik.

A Huawei Technologies, Német Kutatóközpont vezető tárolóépítészeként dolgozom. A virtualizációs osztályon az adattárolás különböző aspektusaival foglalkozom. Tevékenységeim nem egy adott operációs rendszerhez kapcsolódnak.

Jelenleg elkötelezi magát a fő kernel ág mellett?

Nagyon ritkán, és csak akkor, ha a munkáltatóm igényli. Legutóbb körülbelül három éve küldtem javításokat, hogy növeljem a 9p protokollt használó gazdagépeken megosztott tárolási sebességet (a vállalkozás másik neve VirtFS). Itt egy fontos megjegyzést kell tenni: bár régóta dolgozom Linuxszal, soha nem rajongtam érte, vagyis „egyenletesen lélegzem”, mint minden másnál. Különösen, ha hibát észlelek, legfeljebb egyszer tudok rávilágítani. És hogy azután követhess valakit és rávegyen - ez nem fog megtörténni.

Emlékszem, legutóbb, tíz évvel ezelőtt, elég kritikus voltál a kernelfejlesztési stílussal kapcsolatban. Az Ön (vagy esetleg vállalati) szemszögéből nézve változott valami, érzékenyebb lett a közösség vagy sem? Ha nem, szerinted ki a hibás?

Soha nem láttam jobb irányba változást. A közösség fő problémája a tudomány politikai technológiával való felváltása, a személyes kapcsolatok, a többségi vélemény, a populizmus, a „belső hangok” tanácsai, a rohadt kompromisszumok, bármi más, mint a tudomány. A számítástechnika, bármit is mondjunk, mindenekelőtt egzakt tudomány. És ha valaki elkezdi hirdetni a saját értékét a 2-től eltérő 2x4-re a „Linux way” zászló alatt, vagy más zászló alatt, akkor ez nem valószínű, hogy kárt okozna.

Minden baj elsősorban a döntéshozók hozzá nem értéséből, iskolázatlanságából fakad. Ha egy vezető alkalmatlan, nem tud objektív, adekvát döntést hozni. Ha ő is kulturálatlan, nem tud hozzáértő szakembert találni, aki megfelelő tanácsot adna neki. Nagy valószínűséggel egy csalóra esik a választás, aki azt mondja, hogy „látszólag helyes dolgokat”. Mindig korrupt környezet alakul ki az inkompetens magányos vezetők körül. Ráadásul a történelem e tekintetben nem ismer kivételt, és ennek a közösség a legvilágosabb megerősítése.

Hogyan értékeli a Btrfs fejlesztésének előrehaladását? Ez az FS megszabadult a gyermekkori betegségektől? Hogyan pozícionálja saját magának – FS-ként „otthoni” vagy vállalati használatra is?

nem szabadultam meg tőle. Mindaz, amit 11 évvel ezelőtt említettem, ma is aktuális. A Btrfs egyik olyan problémája, amely alkalmatlanná teszi komoly igényekre, a szabad hely problémája. Arról már nem is beszélek, hogy olyan helyzetekben, amikor bármely más FS sok szabad helyet mutatna a partíción, arra kérik a felhasználót, hogy fusson a boltba új lemezért. Az sem a legrosszabb, hogy a szabad hely hiánya miatt képtelenség végrehajtani egy műveletet egy logikai köteten. A legrosszabb az, hogy egy kiváltságtalan felhasználó szinte mindig, bármilyen lemezkvótát megkerülve, meglehetősen rövid időn belül mindenkit megfoszthat a szabad helytől.

Így néz ki (Linux kernel 5.12-re tesztelve). A frissen telepített rendszeren elindul egy szkript, amely egy ciklusban bizonyos nevű fájlokat hoz létre a home könyvtárban, bizonyos eltolásokkal adatokat ír rájuk, majd ezeket a fájlokat törli. Egy perccel a szkript futtatása után semmi szokatlan nem történik. Öt perc elteltével a partíció elfoglalt területe kissé megnő. Két-három óra elteltével eléri az 50%-ot (15%-os kezdeti értékkel). Öt vagy hat óra munka után a szkript összeomlik a „nincs szabad hely a partíción” hibával. Ezt követően már nem tud még 4K fájlt sem írni a partícióra.

Érdekes helyzet áll elő: végül nem írtál semmit a partícióra, és az összes szabad terület (kb. 85%) eltűnt valahol. Egy ilyen támadásnak kitett szakasz elemzése számos facsomópontot fog feltárni, amelyek csak egy elemet tartalmaznak (kulccsal ellátott objektum), több bájt méretű. Vagyis a korábban a lemezterület 15%-át elfoglaló tartalom egyenletesen „elkenődött” a teljes partíción, így nincs hová új fájlt írni, mert a kulcsa nagyobb, mint az összes meglévőé, és a szabad a partíció blokkjai elfogytak.

Sőt, mindez már az alap Btrfs konfigurációban megtörténik (pillanatképek, alkötetek stb. nélkül), és nem mindegy, hogy hogyan dönti el, hogy a fájltörzseket az FS-ben tárolja (egy fában „töredékként”, vagy kiterjedésként). formázatlan blokkokból) - a végeredmény ugyanaz lesz.

Más upstream fájlrendszereket nem fog tudni kitenni ilyen támadásnak (nem számít, mit mondanak). A probléma okát már régen kifejtettem: ez a Btrfs B-fa koncepciójának teljes elferdítése, ami lehetővé teszi, hogy spontán vagy szándékosan elfajuljon. Különösen bizonyos terheléseknél a fájlrendszer folyamatosan „szétromlik” működés közben, külső segítség nélkül. Nyilvánvaló, hogy mindenféle „nyomós” háttérfolyamat csak az egyes asztali gépeken mentheti meg a helyzetet.

A kollektív szervereken a támadó mindig képes lesz „előzni” őket. A rendszergazda még azt sem fogja tudni megállapítani, hogy pontosan ki bántalmazta. A probléma megoldásának leggyorsabb módja a Btrfs-ben egy szabályos B-fa szerkezetének visszaállítása, pl. a lemezformátum újratervezése és a Btrfs kód jelentős részének újraírása. Ez 8-10 évig tart, beleértve a hibakeresést is, feltéve, hogy a fejlesztők szigorúan betartották a vonatkozó algoritmusokról és adatstruktúrákról szóló eredeti cikkeket, és nem a „Broken phone” játékkal játszottak, ahogy az a „Linuxban” megszokott (és javasolt). út".

Itt még hozzá kell adnunk azt az időt is, ami ahhoz szükséges, hogy a fejlesztők megértsék mindezt. Itt egyre nehezebb. 10 év mindenesetre nem volt elég ahhoz, hogy megértsék. Nos, addig nem remélhetsz csodát. Ez nem egy szerelési lehetőség formájában fog megtörténni, „amiről te és én nem tudtunk”, vagy olyan javítás formájában, amelynek előkészítése „csak üzleti kérdés”. Minden ilyen elhamarkodott „javításhoz” bemutatok egy új degenerációs forgatókönyvet. A B-fák az egyik kedvenc témám, és azt kell mondanom, hogy ezek a struktúrák nem tűrnek szabadságot magukkal!

Hogyan pozícionálhatom magamnak a Btrf-eket? Olyan, ami egyáltalán nem nevezhető fájlrendszernek, nemhogy használtnak. Mert az FS értelemszerűen a „lemezterület” erőforrás hatékony kezeléséért felelős operációs rendszer alrendszer, amit a Btrfs esetében nem látunk. Nos, képzeld el, hogy azért jöttél a boltba, hogy órát vásárolj, nehogy elkéss a munkából, és óra helyett maximum 30 perces időzítős elektromos grillt adtak neked. Tehát a Btrfs helyzete még rosszabb.

A levelezési listákat lapozgatva gyakran találkozom azzal az állítással, hogy a lemezterület hatékony kezelése a meghajtók olcsósága miatt már nem aktuális. Ez teljes nonszensz. Hatékony lemezterület-kezelő nélkül az operációs rendszer sebezhetővé és használhatatlanná válik. Függetlenül a gépeden lévő lemezek kapacitásától.

Hozzászólást szeretnék kérni a Btrfs támogatás RHEL-ben történő megszüntetésével kapcsolatban.

Nincs itt semmi különösebb kommentár, minden nagyon világos. Nekik is volt „technológia előnézete”. Szóval, nem nagyon mentem át ezen az „előzetesen”. Ne hagyd, hogy ez a címke örökké lógjon! De nem tudnak teljes támogatással piacra dobni egy hibás by-design terméket. Az RHEL vállalkozás, azaz előírt áru-pénz kapcsolatok. A Red Hat nem bánthatja a felhasználókat, mint a Btrfs levelezőlistáján. Képzelje csak el a helyzetet: egy ügyfél, aki kifizette nehezen megkeresett pénzét a lemezért, és Ön is a támogatásért, szeretné megérteni, hová tűnt a lemezterülete, miután nem írt le semmit. Mit válaszolsz erre neki?

További. A Red Hat ügyfelei közé tartoznak a jól ismert nagy bankok és tőzsdék. Képzeld el, mi történne, ha a Btrfs említett sérülékenysége alapján DoS-támadások érnének. Ön szerint ki a felelős ezért? Aki éppen a GPL licenc azon sorára akar mutogatni, ahol az van írva, hogy a szerző nem felelős semmiért, annak azonnal azt mondom: „bújj el!” A Red Hat válaszol, méghozzá úgy, hogy nem tűnik elégnek! De tudom, hogy a Red Hatnek nem kell ilyen problémával szembesülnie, tekintettel a minőségbiztosítási mérnökök különösen erős csapatára, akikkel az én időmben lehetőségem volt szorosan együttműködni.

Miért támogatják egyes vállalatok továbbra is a Btrf-t vállalati termékeikben?

Felhívjuk figyelmét, hogy a terméknévben szereplő „vállalkozás” előtag nem jelent sokat. A vállalkozás az ügyféllel fennálló szerződéses viszonyba ágyazott felelősség mértéke. Egyetlen GNU/Linux alapú vállalatról tudok – RHEL. Minden más, az én szemszögemből, csak vállalkozásként jelenik meg, de nem az. És végül, ha valamire van kereslet, akkor mindig lesz kínálat (nálunk ez az említett „támogatás”). Abszolút mindenre van kereslet, pl. és használhatatlan szoftver. Egy másik téma, hogy hogyan alakul ki ez a kereslet, és ki táplálja.

Szóval nem vonnék le semmiféle következtetést, miután a pletykák szerint a Facebook Btrfs-t telepített a szervereire. Ezenkívül azt javaslom, hogy a fenti okok miatt gondosan tartsa titokban ezen szerverek címét.

Miért fektettek annyi erőfeszítést az XFS kód megtisztítására mostanában? Végtére is, kezdetben ez egy harmadik féltől származó fájlrendszer, és az ext4 hosszú ideig stabil, és folytonossága van a korábbi ugyanolyan stabil verziókhoz képest. Milyen érdeke van a Red Hatnek az XFS iránt? Van értelme aktívan fejleszteni két hasonló célú fájlrendszert - ext4 és XFS?

Nem emlékszem, mi motiválta ezt. Nagyon valószínű, hogy a kezdeményezés a Red Hat ügyfeleitől származott. Emlékszem, hogy végeztek ilyen jellegű kutatásokat: néhány upstream fájlrendszeren óriási számú objektumot hoztak létre az új generációs csúcskategóriás meghajtókon. Az eredmények szerint az XFS jobban viselkedett, mint az ext4. Ezért elkezdték népszerűsíteni, mint a legígéretesebbet. Mindenesetre nem keresnék itt semmi szenzációt.

Számomra olyan, mintha szappanra cserélték volna a csűrt. Nincs értelme ext4-et és XFS-t fejleszteni. Párhuzamosan és bármelyik közül lehet választani. Ebből semmi jó nem sül ki. Bár a természetben gyakran vannak olyan helyzetek, amikor sok a növekedési lehetőség, de nincs hely a növekedésre. Ebben az esetben különféle bizarr csúnya új növedékek keletkeznek, amelyekre mindenki ujjal mutat („Ó, nézd, mit nem fogsz látni ebben az életben!”).

Szerinted a rétegek megsértése megoldódott (negatív értelemben) az ext4, F2FS titkosítási funkciók megjelenésével (a Btrfs-ben a RAID-ről nem is beszélve)?

Általánosságban elmondható, hogy bármely szint bevezetése és a meg nem sértésükről szóló döntés általában szakpolitikai kérdés, és itt nem vállalkozom arra, hogy bármit is kommentáljak. A rétegsértés objektív vonatkozásai senkit nem érdekelnek, de néhányat megfontolhatunk a sértés „felülről” példáján, nevezetesen a blokkrétegen már létező funkcionalitás FS-ben való megvalósításával. Az ilyen „jogsértés” csak ritka kivételektől eltekintve indokolt. Minden ilyen esethez először két dolgot kell bizonyítania: hogy valóban szükség van rá, és hogy a rendszer kialakítása nem fog ártani ezzel.

Például a tükrözést, amely hagyományosan a blokkréteg tevékenysége, ésszerű a fájlrendszer szintjén megvalósítani. Különböző okokból. Például „néma” adatsérülés (bit rothadás) fordul elő a lemezmeghajtókon. Ilyenkor a készülék megfelelően működik, de a blokkadatok váratlanul megsérülnek egy távoli kvazár által kibocsátott kemény gamma-kvantum hatására stb. A legrosszabb az, ha ez a blokk FS rendszerblokknak bizonyul (szuperblokk, bittérkép blokk, tárolófa csomópont stb.), mert ez minden bizonnyal kernelpánikhoz vezet.

Kérjük, vegye figyelembe, hogy a blokkréteg (ún. RAID 1) által kínált tükrök nem mentik meg Önt ettől a problémától. Nos, tényleg: valakinek ellenőriznie kell az ellenőrző összegeket, és hiba esetén elolvasnia a replikát? Ezen túlmenően célszerű nemcsak mindent, hanem csak a metaadatokat tükrözni. Néhány fontos adat (például a kritikus alkalmazások futtatható fájljai) metaadatként tárolható. Ebben az esetben ugyanazokat a biztonsági garanciákat kapják. A fennmaradó adatok védelmét célszerű más alrendszerekre (esetleg felhasználói alkalmazásokra) bízni – ehhez minden szükséges feltételt biztosítottunk.

Az ilyen „gazdaságos” tükröknek létjogosultsága van, és csak fájlrendszer szinten lehet őket hatékonyan megszervezni. Ellenkező esetben a rétegzés megsértése az alrendszert duplikált kóddal zsúfolja el bizonyos mikroszkopikus előnyök kedvéért. Ennek frappáns példája a RAID-5 FS segítségével történő megvalósítása. Az ilyen megoldások (saját RAID / LVM a fájlrendszerben) építészeti szempontból megölik az utóbbit. Itt azt is meg kell jegyezni, hogy a rétegsértést a különféle marketinges csalók „folyamatba helyezik”. Ötletek híján a szomszédos szinteken már régóta megvalósított funkcionalitás kerül az alrendszerekbe, ez egy új, rendkívül hasznos funkcióként jelenik meg és aktívan tolódik.

Reiser4-et azzal vádolták, hogy „alulról” megsértette a szinteket. Abból a tényből kiindulva, hogy a fájlrendszer nem monolitikus, mint az összes többi, hanem moduláris, egy megalapozatlan feltételezés született, hogy azt csinálja, amit a fenti szintnek (VFS) kell.

Lehet-e beszélni a ReiserFS v3.6 és például a JFS haláláról? Az utóbbi időben szinte semmi figyelmet nem kaptak a magban. Ezek elavultak?

Itt meg kell határoznunk, hogy mit jelent egy szoftvertermék halála. Egyrészt sikeresen használják őket (végül is erre hozták létre), ami azt jelenti, hogy élnek. Másrészt a JFS-ről nem tudok beszélni (nem tudok sokat), de a ReiserFS-t (v3) nagyon nehéz alkalmazkodni az új trendekhez (a gyakorlatban tesztelve). Ez azt jelenti, hogy a jövőben a fejlesztők nem erre fognak figyelni, hanem a könnyebben adaptálhatókra. Erről az oldalról kiderül, hogy sajnos, építészeti szempontból halott. Egyáltalán nem manipulálnám az „erkölcsileg elavult” fogalmát. Jól alkalmazható például egy ruhásszekrényre, de nem a szoftvertermékekre. Valamiben benne van az alsóbbrendűség és felsőbbrendűség fogalma. Határozottan kijelenthetem, hogy a ReserFS v3 most mindenben rosszabb, mint a Reiser4, de bizonyos típusú terheléseknél jobb, mint az összes többi upstream FS.

Tud az FS Tux3 és a HAMMER/HAMMER2 (FS for DragonFly BSD) fejlesztéséről?

Igen, tudjuk. A Tux3-ban egyszer érdekelt a pillanatképeik (az úgynevezett „verziómutatók”) technológiája, de a Reiser4-ben nagy valószínűséggel más utat fogunk bejárni. Régóta gondolkodom a pillanatképek támogatásán, és még nem döntöttem el, hogyan valósítsam meg őket egyszerű Reiser4 köteteknél. A tény az, hogy az Ohad Rodeh által javasolt „lusta” referenciaszámláló technika csak a B-fák esetében működik. Nálunk nincsenek. A Reiesr4-ben használt adatstruktúrákhoz nincsenek definiálva a „lusta” számlálók - ezek bevezetéséhez meg kell oldani bizonyos algoritmikus problémákat, amelyeket még senki nem vállalt.

HAMMER szerint: Olvastam egy cikket az alkotótól. Nem érdekel. Ismét B-fák. Ez az adatstruktúra reménytelenül elavult. A múlt században elhagytuk.

Hogyan értékeli a hálózati fürt FS-ek, például a CephFS/GlusterFS/stb. iránti növekvő keresletet? Ez az igény azt jelenti, hogy a fejlesztők prioritásai eltolódnak a hálózati FS irányába, és nem fordítanak kellő figyelmet a helyi FS-re?

Igen, ekkora prioritásváltás történt. A helyi fájlrendszerek fejlesztése stagnált. Sajnos, valami jelentőset a helyi kötetek számára ma már meglehetősen nehéz, és nem mindenki teheti meg. Senki nem akar befektetni a fejlesztésükbe. Ez körülbelül ugyanaz, mintha egy kereskedelmi szervezettől kérnénk pénzt matematikai kutatásra – minden lelkesedés nélkül megkérdezik, hogyan lehet pénzt keresni egy új tétellel. Most egy helyi FS olyan valami, ami varázsütésre megjelenik a „dobozból” és „mindig működnie kell”, és ha nem működik, akkor címzetlen zúgolódást vált ki, például: „Igen, mire gondolnak!”

Innen ered a figyelem hiánya a helyi FS-re, bár még mindig sok munka van ezen a területen. És igen, mindenki az elosztott tárolás felé fordult, amely a már meglévő helyi fájlrendszerekre épül. Ez most nagyon divatos. A „Big Data” kifejezés sokak számára adrenalint okoz, konferenciákkal, workshopokkal, nagy fizetésekkel stb.

Mennyire ésszerű elvileg a hálózati fájlrendszert a kerneltérben megvalósítani, nem pedig a felhasználói térben?

Nagyon ésszerű megközelítés, amelyet még sehol nem alkalmaztak. Általánosságban elmondható, hogy az a kérdés, hogy milyen térben kell egy hálózati fájlrendszert megvalósítani, „kétélű fegyver”. Nos, nézzünk egy példát. Az ügyfél egy távoli gépen rögzítette az adatokat. Piszkos oldalak formájában kerültek az oldal gyorsítótárába. Ez a feladat egy "vékony átjáró" hálózati fájlrendszerhez a kerneltérben. Ekkor az operációs rendszer előbb-utóbb megkéri, hogy írja lemezre ezeket az oldalakat, hogy felszabadítsa őket. Ezután az IO-továbbítási (küldő) hálózati FS modul lép működésbe. Meghatározza, hogy ezek az oldalak melyik szervergépre (szervercsomópontra) kerüljenek.

Ezután a hálózati verem veszi át az irányítást (és mint tudjuk, kerneltérben valósul meg). Ezután a kiszolgáló csomópontja megkapja az adatokat vagy metaadatokat tartalmazó csomagot, és utasítja a háttértároló modult (azaz a kernelterületen működő helyi FS-t), hogy rögzítse mindezt. Tehát a kérdést arra redukáltuk, hogy hol működjön a „küldő” és „fogadó” modul. Ha ezen modulok bármelyike ​​a felhasználói térben fut, az elkerülhetetlenül kontextusváltáshoz vezet (a kernelszolgáltatások használatának szükségessége miatt). Az ilyen kapcsolók száma a megvalósítás részleteitől függ.

Ha sok ilyen kapcsoló van, akkor a tárolási teljesítmény (I/O teljesítmény) csökken. Ha a háttértár lassú lemezekből áll, akkor nem fog észrevenni jelentős csökkenést. De ha gyors lemezeink vannak (SSD, NVRAM stb.), akkor a kontextusváltás már „szűk keresztmetszetté” válik, és a kontextusváltáson spórolva a teljesítmény jelentősen növelhető. A pénzmegtakarítás szokásos módja a modulok kernelterületre való áthelyezése. Például azt találtuk, hogy a 9p szerver áthelyezése a QEMU-ból a gazdagép kernelébe a VirtFS teljesítményének háromszorosához vezet.

Ez persze nem hálózati FS, de a dolgok lényegét teljes mértékben tükrözi. Ennek az optimalizálásnak a hátránya a hordozhatósági problémák. Egyesek számára ez utóbbi kritikus lehet. Például a GlusterFS egyáltalán nem tartalmaz modulokat a kernelben. Ennek köszönhetően ma már számos platformon működik, beleértve a NetBSD-t is.

Milyen koncepciókat kölcsönözhetnének a helyi FS-ek a hálózati koncepcióktól és fordítva?

Manapság a hálózati FS-ek általában rendelkeznek kiegészítőkkel a helyi FS-ekhez, így nem egészen értem, hogyan lehet ez utóbbiaktól kölcsönözni valamit. Nos, valóban, tekintsünk egy 4 fős céget, amelyben mindenki a maga dolgát végzi: az egyik oszt, a másik küld, a harmadik fogad, a negyedik tárol. És valahogy helytelenül hangzik a kérdés, hogy mit kölcsönözhet a cég az azt tároló alkalmazottjától (már rég megvan, amit kölcsönkérhetett volna tőle).

De a helyi FS-eknek sokat kell tanulniuk a hálózatiaktól. Először is meg kell tanulnia tőlük a logikai kötetek magas szintű összesítését. Most az ún A „fejlett” helyi fájlrendszerek a logikai köteteket kizárólag az LVM-től kölcsönzött „virtuális eszköz” technológiával aggregálják (ugyanaz a fertőző rétegződés megsértése, amelyet először a ZFS-ben alkalmaztak). Más szavakkal, a virtuális címek (blokkszámok) valós címekre és visszafordítása alacsony szinten történik (azaz miután a fájlrendszer I/O kérést adott ki).

Felhívjuk figyelmét, hogy a blokkrétegen elhelyezett logikai kötetekhez (nem tükrökhöz) eszközök hozzáadása és eltávolítása olyan problémákhoz vezet, amelyekről az ilyen „szolgáltatások” szállítói szerényen hallgatnak. A valós eszközökön a töredezettségről beszélek, ami iszonyatos értékeket érhet el, míg egy virtuális készüléken minden rendben van. A virtuális eszközök azonban kevesen érdeklődnek: mindenkit érdekel, hogy mi történik a valódi eszközein. De a ZFS-szerű FS (valamint az LVM-mel együtt bármilyen FS) csak virtuális lemezeszközökkel működik (virtuális lemezcímek kiosztása az ingyenesek közül, töredezettségmentesítése ezeknek a virtuális eszközöknek stb.). És fogalmuk sincs, mi történik a valódi eszközökön!

Most képzelje el, hogy a virtuális eszközön nincs töredezettség (vagyis csak egy óriási kiterjedés él ott), hozzáad egy lemezt a logikai kötetéhez, majd eltávolít egy másik véletlenszerű lemezt a logikai kötetből, majd újra egyensúlyozza. És annyiszor. Nem nehéz elképzelni, hogy a virtuális eszközön még mindig ugyanannyit fog élni, de valódi eszközökön semmi jót nem fog látni.

A legrosszabb az, hogy még ezt a helyzetet sem tudod korrigálni! Itt csak annyit tehet, hogy megkéri a fájlrendszert a virtuális eszköz töredezettségmentesítésére. De azt fogja mondani, hogy ott minden nagyszerű - csak egy mérték van, a töredezettség nulla, és nem is lehet jobb! Tehát a blokkszinten elhelyezett logikai kötetek nem az eszközök ismételt hozzáadására/eltávolítására szolgálnak. Jó értelemben csak egyszer kell blokkszinten összerakni egy logikai kötetet, odaadni a fájlrendszernek, és utána nem kell mást csinálni vele.

Ezenkívül a független FS+LVM alrendszerek kombinációja nem teszi lehetővé azon meghajtók eltérő jellegének figyelembe vételét, amelyekről a logikai kötetek aggregálódnak. Valóban, tegyük fel, hogy összeállított egy logikai kötetet HDD-ből és szilárdtestalapú eszközökből. De akkor az előbbi töredezettségmentesítést igényel, az utóbbi pedig nem. Utóbbihoz eldobási kérelmeket kell kiadni, előbbihez viszont nem stb. Ebben a kombinációban azonban meglehetősen nehéz ilyen szelektivitást kimutatni.

Vegye figyelembe, hogy miután létrehozta saját LVM-jét a fájlrendszeren, a helyzet nem lesz sokkal jobb. Sőt, ezzel tulajdonképpen véget vetsz annak a lehetőségnek, hogy a jövőben folyamatosan javítsd. Ez nagyon rossz. Különböző típusú meghajtók működhetnek ugyanazon a gépen. És ha a fájlrendszer nem tesz különbséget közöttük, akkor ki fog?

Egy másik probléma leselkedik az ún. “Write-Anywhere” fájlrendszerek (ebbe a Reiser4 is beletartozik, ha a csatlakoztatás során megadta a megfelelő tranzakciós modellt). Az ilyen fájlrendszereknek olyan töredezettségmentesítő eszközöket kell biztosítaniuk, amelyek erejükben példátlanok. Az alacsony szintű hangerő-kezelő pedig itt nem segít, hanem csak akadályoz. A helyzet az, hogy egy ilyen kezelővel az FS csak egy eszköz ingyenes blokkjainak térképét tárolja - egy virtuális. Ennek megfelelően csak virtuális eszközt tud töredezettségmentesíteni. Ez azt jelenti, hogy a töredezettségmentesítője hosszú-hosszú ideig fog működni a virtuális címek hatalmas, egyetlen területén.

És ha sok felhasználó végez véletlenszerű felülírást, akkor egy ilyen töredezettség-mentesítő hasznos hatása nullára csökken. Rendszere elkerülhetetlenül lassulni kezd, és csak össze kell törnie a kezét a kiábrándító diagnózis „törött tervezése” előtt. Több, ugyanazon a címterületen futó töredezettség-mentesítő csak zavarja egymást. Teljesen más kérdés, ha minden valódi eszközhöz saját ingyenes blokktérképet tart fenn. Ez hatékonyan párhuzamosítja a töredezettségmentesítési folyamatot.

De ez csak akkor lehetséges, ha magas szintű logikai kötetkezelővel rendelkezik. Ilyen kezelőkkel rendelkező helyi fájlrendszerek korábban nem léteztek (legalábbis én nem tudok róluk). Csak a hálózati fájlrendszerek (például a GlusterFS) rendelkeztek ilyen kezelőkkel. Egy másik nagyon fontos példa a kötet integritását ellenőrző (fsck) segédprogram. Ha minden egyes részkötethez saját független térképet tárol szabad blokkokról, akkor a logikai kötet ellenőrzési eljárása hatékonyan párhuzamosítható. Más szóval, a magas szintű menedzserekkel rendelkező logikai kötetek jobban méretezhetők.

Ezenkívül az alacsony szintű hangerő-kezelőkkel nem lesz képes teljes értékű pillanatképeket rendezni. Az LVM és a ZFS-szerű fájlrendszerekkel csak helyi pillanatképek készíthetők, globális pillanatképek nem. A helyi pillanatképek lehetővé teszik, hogy csak a szokásos fájlműveleteket állítsa vissza azonnal. És ott senki sem fogja visszaállítani a logikai kötetekkel végzett műveleteket (eszközök hozzáadása/eltávolítása). Nézzük ezt egy példával. Egy bizonyos időpontban, amikor két A és B eszköz logikai kötete 100 fájlt tartalmaz, készít egy pillanatképet az S rendszerről, majd hoz létre további száz fájlt.

Ezt követően hozzáadja a C eszközt a kötetéhez, végül visszaállítja a rendszert az S pillanatképhez. Kérdés: Hány fájlt és eszközt tartalmaz a logikai kötet az S-re való visszaállítás után? 100 fájl lesz, ahogy sejtette, de 3 eszköz lesz - ezek ugyanazok az A, B és C eszközök, bár a pillanatkép készítésekor csak két eszköz volt a rendszerben (A és B ). A C eszköz hozzáadása művelet nem gördült vissza, és ha most eltávolítja a C eszközt a számítógépről, az megsérti az adatait, így a törlés előtt először el kell végeznie egy költséges műveletet, hogy eltávolítsa az eszközt a logikai egyensúly helyreállításáról, ami szétszórja az összes adatot a C eszközről az A és B eszközökre. De ha az FS támogatja a globális pillanatképeket, akkor nincs szükség ilyen újraegyensúlyozásra, és az S-re való azonnali visszaállítás után biztonságosan eltávolíthatja a C eszközt a számítógépről.

Tehát a globális pillanatképek azért jók, mert lehetővé teszik, hogy elkerülje egy eszköz költséges eltávolítását (hozzáadását) egy nagy mennyiségű adatot tartalmazó logikai kötetről (logikai kötethez) (persze, ha eszébe jut a rendszer „pillanatfelvétele” a megfelelő időben). Hadd emlékeztesselek arra, hogy a pillanatképek létrehozása és a fájlrendszer visszaállítása azonnali művelet. Felmerülhet a kérdés: hogyan lehetséges, hogy egy három napig tartó logikai köteten azonnal visszagurítson egy műveletet? De lehetséges! Feltéve, hogy a fájlrendszert megfelelően tervezték. Három éve jutott eszembe az ilyen „3D pillanatképek” ötlete, és tavaly szabadalmaztattam ezt a technikát.

A következő dolog, amit a helyi FS-eknek meg kell tanulniuk a hálózati eszközöktől, az az, hogy a metaadatokat különálló eszközökön tárolják, ugyanúgy, ahogy a hálózati FS-ek külön gépeken (az úgynevezett metaadat-szervereken) tárolják azokat. Vannak olyan alkalmazások, amelyek elsősorban metaadatokkal dolgoznak, és ezek az alkalmazások nagymértékben felgyorsíthatók, ha a metaadatokat drága, nagy teljesítményű tárolóeszközökre helyezik. Az FS+LVM kombinációval nem fog tudni ilyen szelektivitást kimutatni: az LVM nem tudja, mi van azon a blokkon, amelyet átadott neki (ott adatok vagy metaadatok).

Az FS+LVM kombinációhoz képest nem sok haszna lesz abból, ha saját alacsony szintű LVM-jét implementálja az FS-be, de amit nagyon jól megtehet, az az, hogy összezavarja az FS-t, így később lehetetlenné válik a kódjával való munka. A virtuális eszközökkel rohanó ZFS és Btrfs mind világos példák arra, hogy a rétegsértés hogyan öli meg a rendszert építészeti szempontból. Szóval miért vagyok mindez? Ezenkívül nincs szükség saját alacsony szintű LVM telepítésére a fájlrendszerben. Ehelyett az eszközöket magas szinten logikai kötetekbe kell összesíteni, ahogy azt egyes hálózati fájlrendszerek teszik a különböző gépekkel (tárolócsomópontokkal). Igaz, ezt a rossz algoritmusok használata miatt undorítóan teszik.

Az abszolút szörnyű algoritmusokra példa a DHT fordító a GlusterFS fájlrendszerben és az úgynevezett CRUSH térkép a Ceph fájlrendszerben. Az általam látott algoritmusok egyike sem elégedett meg az egyszerűség és a jó méretezhetőség tekintetében. Így hát emlékeznem kellett az algebrára, és mindent magamnak kellett kitalálnom. 2015-ben, miközben kísérleteztem a kötegekkel a hash függvények felett, kitaláltam és szabadalmaztattam valamit, ami megfelel nekem. Most már elmondhatom, hogy az a kísérlet, hogy mindezt a gyakorlatba is átültessék, sikeres volt. Az új megközelítésben nem látok problémát a skálázhatósággal kapcsolatban.

Igen, minden alkötethez külön struktúra kell, például egy szuperblokk a memóriában. Ez nagyon ijesztő? Általánosságban elmondható, hogy nem tudom, ki fogja „forralni az óceánt”, és több százezer vagy több eszközből álló logikai köteteket hoz létre egyetlen helyi gépen. Ha valaki ezt el tudná nekem magyarázni nagyon megköszönném. Addig is számomra ez marketing baromság.

Hogyan befolyásolták a kernelblokk eszköz alrendszerében bekövetkezett változások (például a blk-mq megjelenése) az FS megvalósítás követelményeit?

Semmi hatásuk nem volt. Nem tudom, mi történne a blokkrétegen, ami szükségessé tenné egy új FS tervezését. Ezen alrendszerek interakciós felülete nagyon gyenge. Meghajtó oldalról az FS-t csak az új típusú meghajtók megjelenése érintheti, amelyekhez először a blokkréteg, majd az FS lesz igazítva (reiser4-nél ez új pluginok megjelenését jelenti).

Az új típusú adathordozók megjelenése (például az SMR vagy az SSD-k elterjedése) alapvetően új kihívásokat jelent a fájlrendszer-tervezésben?

Igen. És ezek normális ösztönzők az FS fejlődéséhez. A kihívások különbözőek és teljesen váratlanok lehetnek. Például hallottam olyan meghajtókról, ahol egy I/O művelet sebessége nagymértékben függ egy adat méretétől és eltolásától. Linuxban, ahol az FS blokk mérete nem haladhatja meg az oldal méretét, az ilyen meghajtó alapértelmezés szerint nem mutatja meg teljes képességét. Ha azonban a fájlrendszert megfelelően tervezték meg, akkor esély van arra, hogy sokkal többet hozzon ki belőle.

Hányan dolgoznak jelenleg a Reiser4 kóddal rajtad kívül?

Kevesebbet, mint szeretném, de akut forráshiányt sem tapasztalok. Több mint elégedett vagyok a Reiser4 fejlesztési ütemével. Nem fogok „lovakat hajtani” – ez nem a megfelelő terület. Itt: "Ha halkabban vezetsz, akkor megy tovább!" A modern fájlrendszer a legbonyolultabb kernel-alrendszer, amelynek rossz tervezési döntései visszavonhatják a következő évek emberi munkáját.

Azzal, hogy önkénteseket ajánlok fel valami megvalósítására, mindig garantálom, hogy az erőfeszítések minden bizonnyal megfelelő eredményre vezetnek, amelyre komoly igények is lehetnek. Mint érti, nem lehet sok ilyen garancia egyszerre. Ugyanakkor ki nem állhatom azokat a „figurákat”, akik szemérmetlenül népszerűsítik a nyilvánvalóan használhatatlan szoftverek „funkcióit”, megtévesztve a felhasználók és fejlesztők százait, és közben ülnek és mosolyognak a kernelcsúcsokon.

Kinyilvánította-e valamelyik vállalat a Reiser4 fejlesztésének támogatására irányuló szándékát?

Igen, voltak ilyen javaslatok, pl. és egy jelentős eladótól. De ehhez el kellett költöznöm egy másik országba. Sajnos már nem vagyok 30 éves, nem tudok elszakadni és így elmenni az első sípszóra.

Milyen funkciók hiányoznak jelenleg a Reiser4-ből?

Egyszerű köteteknél nincs „átméretezés” funkció, hasonlóan a ReiserFS(v3)-ban találhatóhoz. Ezenkívül a DIRECT_IO jelzővel végzett fájlműveletek sem ártanak. Ezt követően szeretném, ha egy kötetet „szemantikai részkötetekre” lehetne szétválasztani, amelyeknek nincs fix mérete, és amelyek önálló kötetként is felszerelhetők. Ezek a problémák jók azoknak a kezdőknek, akik szeretnék kipróbálni magukat az „igaziban”.

És végül szeretnék hálózati logikai köteteket egyszerű implementációval és adminisztrációval (a modern algoritmusok ezt már lehetővé teszik). De ami a Reiser4-nek biztosan soha nem lesz, az a RAID-Z, a scrubok, a szabad hely gyorsítótárak, a 128 bites változók és egyéb marketinges hülyeségek, amelyek néhány fájlrendszer fejlesztőinek ötlethiánya miatt merültek fel.

Minden, amire szükség lehet, megvalósítható pluginekkel?

Ha csak az interfészekről és az azokat megvalósító bővítményekről (modulokról) beszélünk, akkor nem mindenről. De ha ezeken az interfészeken kapcsolatokat is bevezet, akkor többek között meglesz a magasabb polimorfizmus fogalma, amivel már meg lehet boldogulni. Képzelje el, hogy elméletileg lefagyasztott egy objektumorientált futásidejű rendszert, megváltoztatta az utasításmutató értékét, hogy egy másik beépülő modulra mutasson, amely ugyanazt az X interfészt valósítja meg, majd feloldotta a rendszer rögzítését, hogy az folytassa a végrehajtást.

Ha a végfelhasználó nem észlel ilyen „helyettesítést”, akkor azt mondjuk, hogy a rendszer nulladrendű polimorfizmussal rendelkezik az X interfészben (vagy a rendszer heterogén az X interfészben, ami ugyanaz). Ha most már nemcsak interfészkészletünk van, hanem kapcsolatok is vannak rajtuk (interfész gráf), akkor magasabb rendű polimorfizmusokat vezethetünk be, amelyek már bármely interfész „szomszédságában” jellemezni fogják a rendszer heterogenitását. Már régen bevezettem egy ilyen besorolást, de sajnos nem történt meg.

Tehát a pluginek és az ilyen magasabb polimorfizmusok segítségével bármilyen ismert tulajdonságot leírhatunk, illetve „megjósolhatunk” olyanokat is, amelyekről soha nem is esett szó. Ezt szigorúan nem tudtam bizonyítani, de ellenpéldát sem tudok még. Általában ez a kérdés Felix Klein „Erlangen-programjára” emlékeztetett. Egy időben az egész geometriát az algebra (pontosabban a csoportelmélet) ágaként próbálta ábrázolni.

Most pedig a fő kérdéshez: hogyan haladnak a dolgok a Reiser4 fő magba való promóciójával? Voltak olyan publikációk ennek a fájlrendszernek az architektúrájáról, amelyről a legutóbbi interjúban beszélt? Mennyire releváns ez a kérdés az Ön szemszögéből?

Általánosságban elmondható, hogy három éve kérjük a főági felvételt. Reiser utolsó megjegyzése a nyilvános szálban, ahol a lehívási kérelmet benyújtották, válasz nélkül maradt. Tehát minden további kérdés nem nekünk szól. Én személy szerint nem értem, miért kell „beolvadnunk” egy adott operációs rendszerbe. Linuxon a fény nem konvergált ékszerűen. Tehát van egy külön tárház, amelyben több elágazó port található a különböző operációs rendszerekhez. Akinek szüksége van rá, klónozhatja a megfelelő portot és azt csinál vele, amit akar (természetesen a licencen belül). Nos, ha valakinek nincs rá szüksége, az nem az én problémám. Ezen a ponton azt javaslom, hogy a „fő Linux kernelbe való előléptetés” kérdését tekintsük megoldottnak.

Az FS architektúrával kapcsolatos publikációk relevánsak, de eddig csak az általam kiemelt fontosságúnak tartott új eredményeimre találtam időt. Másik dolog, hogy matematikus vagyok, és a matematikában minden publikáció a tételek összefoglalása és azok bizonyítása. A rossz ízlés jele, ha bármit bizonyíték nélkül közzétesznek ott. Ha alaposan bebizonyítok vagy cáfolok bármilyen állítást az FS architektúrájáról, akkor az eredmény akkora halom lesz, amin elég nehéz lesz átjutni. Kinek van szüksége rá? Valószínűleg ezért marad minden a régi formájában – a forráskód és a hozzá fűzött megjegyzések.

Milyen újdonságok történtek a Reiser4-ben az elmúlt néhány évben?

A régóta várt stabilitás végre megvalósult. Az egyik legutolsó hiba egy olyan hiba volt, amely „törölhetetlen” könyvtárakhoz vezetett. A nehézség az volt, hogy csak a névkivonat-ütközések hátterében és a címtárrekordok meghatározott helyén jelent meg egy fa csomópontjában. A Reiser4-et azonban továbbra sem ajánlom éles használatra: ehhez az éles rendszeradminisztrátorokkal való aktív interakcióval kell dolgozni.

Végre sikerült megvalósítanunk régóta fennálló ötletünket - a különböző tranzakciós modelleket. Korábban a Reiser4 csak egy keménykódolt Macdonald-Reiser modellt futtatott. Ez tervezési problémákat okozott. Különösen a pillanatképek nem lehetségesek egy ilyen tranzakciós modellben – ezeket egy „OVERWRITE SET” nevű atomi összetevő rontja el. A Reiser4 jelenleg három tranzakciós modellt támogat. Az egyikben (Write-Anywhere) az atomi komponens OVERWRITE SET csak rendszeroldalakat tartalmaz (lemez bittérképek, stb.), amelyeket nem lehet „fényképezni” (a tyúk és tojás probléma).

Így a képek most a lehető legjobb módon valósíthatók meg. Egy másik tranzakciós modellben minden módosított oldal csak az OVERWRITE SET-be kerül (vagyis ez lényegében tiszta naplózás). Ez a modell azoknak való, akik panaszkodtak a Reiser4 partíciók gyors töredezettségére. Ebben a modellben a partíció nem töredezett gyorsabban, mint a ReiserFS (v3) esetén. Mindhárom létező modell bizonyos fenntartásokkal garantálja a műveletek atomitását, de hasznosak lehetnek az atomitást vesztett, csak a szakasz integritását megőrző modellek is. Az ilyen modellek mindenféle alkalmazáshoz (adatbázisokhoz stb.) hasznosak lehetnek, amelyek már fel is vettek néhány ilyen funkciót. Nagyon könnyű hozzáadni ezeket a modelleket a Reiser4-hez, de nem tettem meg, mert senki nem kért tőlem, és személy szerint nincs is rá szükségem.

Megjelentek a metaadat-ellenőrző összegek, amelyeket nemrég egészítettem ki „gazdaságos” tükrökkel” (még instabil anyag). Ha bármelyik blokk ellenőrző összege meghiúsul, a Reiser4 azonnal kiolvassa a megfelelő blokkot a replikaeszközről. Vegye figyelembe, hogy a ZFS és a Btrfs nem teheti ezt meg: a tervezés nem teszi lehetővé. Itt le kell futtatnia egy speciális háttér-ellenőrzési folyamatot, az úgynevezett „scrub”-ot, és meg kell várnia, amíg az eléri a problémás blokkot. A programozók képletesen „mankóknak” nevezik az ilyen eseményeket.

És végül megjelentek a heterogén logikai kötetek, amelyek mindent kínálnak, amit a ZFS, Btrfs, blokkréteg, valamint az FS+LVM kombinációk elvileg nem tudnak - párhuzamos skálázás, O(1) lemezcím-kiosztó, transzparens adatmigráció az alkötetek között. Utóbbi felhasználói felülettel is rendelkezik. Mostantól könnyedén áthelyezheti a legforróbb adatokat a kötet legnagyobb teljesítményű meghajtójára.

Ezenkívül lehetőség van a piszkos oldalak sürgős áthúzására egy ilyen meghajtóra, ami jelentősen felgyorsítja a gyakran fsync(2)-t hívó alkalmazásokat. Megjegyzem, hogy a bcache nevű blokkréteg funkció egyáltalán nem biztosít ilyen cselekvési szabadságot. Az új logikai kötetek az én algoritmusaimra épülnek (vannak megfelelő szabadalmak). A szoftver már elég stabil, teljesen ki lehet próbálni, mérni a teljesítményt stb. Az egyetlen kellemetlenség az, hogy egyelőre manuálisan kell frissítenie a kötetkonfigurációt, és el kell tárolnia valahol.

Eddig 10 százalékban tudtam megvalósítani az elképzeléseimet, de sikerült az általam legnehezebbnek tartott dolog - logikai kötetek összekapcsolása egy flash eljárással, amely minden függőben lévő műveletet végrehajt a reiser4-ben. Mindez még a kísérleti „formátum41” ágban van.

A Reiser4 átmegy az xfstesteken?

Legalábbis nekem így volt, amikor az utolsó kiadást készítettem elő.

Lehetséges elvileg a Reiser4-et hálózati (cluster) FS-vé tenni pluginok segítségével?

Lehetséges, sőt szükséges is! Ha egy megfelelően megtervezett helyi fájlrendszeren alapuló hálózati fájlt hoz létre, az eredmény nagyon lenyűgöző lesz! A modern hálózati FS-ekben nem vagyok megelégedve egy háttértárszint jelenlétével, amelyet bármely helyi FS-sel megvalósítanak. Ennek a szintnek a léte teljesen indokolatlan. A hálózati FS-nek közvetlenül interakcióba kell lépnie a blokkréteggel, és nem kérheti a helyi FS-t, hogy hozzon létre más szolgáltatásfájlokat!

Általánosságban elmondható, hogy a fájlrendszerek helyi és hálózati felosztása a gonosztól származik. A harminc évvel ezelőtt használt algoritmusok tökéletlenségéből fakadt, amelyek helyett még nem javasoltak semmit. Ez az oka annak is, hogy tömegesen jelennek meg a felesleges szoftverkomponensek (különböző szolgáltatások, stb.). Jó értelemben csak egy FS-nek kell lennie egy kernelmodul formájában, és minden egyes gépen egy sor felhasználói segédprogram legyen telepítve - egy fürtcsomópont. Ez az FS helyi és hálózati is. És semmi több!

Ha semmi sem működik a Reiser4-el Linuxon, szeretnék felajánlani egy FS-t FreeBSD-hez (idézet egy korábbi interjúból: „...A FreeBSD... tudományos gyökerei vannak... És ez azt jelenti, hogy nagy valószínűséggel megtalálja a közös nyelvet a fejlesztőkkel”)?

Tehát, mint most megtudtuk, már minden tökéletesen működött Linux alatt: külön működő Reiser4 port található hozzá a tárhelyünk mesterága formájában. Nem feledkeztem meg a FreeBSD-ről! Ajánlat! Készen állok arra, hogy szorosan együttműködjek azokkal, akik jól ismerik a FreeBSD belsejét. Amúgy: amit nagyon szeretek a közösségükben, az az, hogy ott egy felfrissített független szakértői tanács hozza meg a döntéseket, aminek semmi köze egy állandó személy kormányzati megtévesztéséhez.

Hogyan értékeli a mai Linux felhasználói közösséget? "poposabb" lett?

Munkám jellegéből adódóan ezt meglehetősen nehéz értékelnem. Leginkább a felhasználók fordulnak hozzám hibajelentésekkel és kérik a rész javítását. Felhasználók, mint felhasználók. Van aki hozzáértőbb, van aki kevésbé. Mindenkit egyformán kezelnek. Nos, ha a felhasználó figyelmen kívül hagyja az utasításaimat, akkor elnézést: részemről is bekerül a figyelmen kívül hagyási parancs.

Megjósolható-e a fájlrendszerek fejlődése a következő öt-tíz évre? Ön szerint melyek a fő kihívások, amelyekkel az FS-fejlesztők szembesülhetnek?

Igen, nem nehéz ilyen előrejelzést készíteni. A felfelé irányuló fájlrendszerek fejlesztése sokáig nem történt meg. Az ilyeneknek csak a látszata jön létre. A helyi fájlrendszerek fejlesztői a rossz tervezéssel kapcsolatos problémákba ütköztek. Itt egy figyelmeztetést kell tenni. A kód úgynevezett „tárolását”, „nyalogatását” és portolását nem tartom fejlesztésnek és fejlesztésnek. A „Btrfs”-nek nevezett félreértést pedig nem minősítem fejleménynek a már kifejtett okok miatt.

Minden javítás csak súlyosbítja a problémáit. Jól. és mindig vannak különféle „evangélisták”, akiknek „minden működik”. Alapvetően iskolásokról és előadásokat kihagyó hallgatókról van szó. Képzeld csak el: neki működik, de a professzornak nem. Micsoda adrenalinlöket ez! Az én szemszögemből a legnagyobb kárt a „mesteremberek” okozzák, akik rohantak lelkesen „csavarni” a Btrfs csodálatos tulajdonságait mindenféle rétegre, mint systemd, docker stb. - ez már metasztázisokhoz hasonlít.

Próbáljunk most öt-tíz évre szóló előrejelzést készíteni. Már röviden felsoroltam, hogy mit fogunk csinálni a Reiser4-ben. Az upstream helyi FS-fejlesztői számára a fő kihívás az lesz (igen, ez már azzá vált), hogy nem tudnak tisztességes munkát végezni fizetésért. Adattárolás terén minden ötlet nélkül tovább próbálkoznak ezen szerencsétlen VFS, XFS és ext4 foltozásával. A VFS helyzete különösen komikusnak tűnik ebben a háttérben, egy étterem őrült modernizációjára emlékeztet, amelyben nincsenek szakácsok, és nem is várnak séfeket.

Most a VFS-kód, minden feltétel nélkül, egyszerre több memórialapot zárol, és felkéri a mögöttes FS-t, hogy működjön rajtuk. Ezt azért vezették be, hogy javítsák az Ext4 teljesítményét a törlési műveleteknél, de amint az könnyen érthető, az ilyen párhuzamos zárolás teljesen összeegyeztethetetlen a fejlett tranzakciós modellekkel. Ez azt jelenti, hogy nem fogja tudni egyszerűen hozzáadni néhány intelligens fájlrendszer támogatását a kernelben. Nem tudom, mi a helyzet a Linux más területein, de ami a fájlrendszereket illeti, nem valószínű, hogy itt bármilyen fejlesztés összeegyeztethető a Torvalds által a gyakorlatban követett politikával (az akadémiai projekteket kirúgják, és a csalók, akik fogalmam sincs, mi a B-fa, végtelen bizalmi krediteket bocsátanak ki). Ezért a lassú pusztulás irányát jelölték ki. Természetesen minden erejükkel megpróbálják ezt „fejlődésnek” adni.

Továbbá a fájlrendszerek „őrzői”, felismerve, hogy a „tárolásból” önmagában nem lehet sokat keresni, egy jövedelmezőbb üzletben próbálják ki magukat. Ezek általában az elosztott fájlrendszerek és a virtualizáció. Talán a divatos ZFS-t máshová helyezik át, ahol még nem létezik. De ez is, mint minden FS a upstreamről, egy újévi fára hasonlít: ha más apróságokat is fel lehet akasztani a tetejére, akkor nem lehet mélyebbre jutni. Elismerem, hogy ZFS-re lehet komoly vállalati rendszert építeni, de mivel most a jövőről beszélünk, csak szomorúan tudom megállapítani, hogy a ZFS ebben a tekintetben reménytelen: a virtuális eszközeikkel a srácok elzárták az oxigént. maguk és a jövő nemzedékei számára a további fejlődés érdekében. A ZFS a múlté. Az ext4 és az XFS pedig nem is tegnapelőtt.

Külön érdemes megemlíteni a „Linux következő generációs fájlrendszerének” szenzációs koncepcióját. Ez egy teljesen politikai és marketing projekt, amelyet arra a lehetőségre hoztak létre, hogy úgy mondjam, „a fájlrendszerek jövőjét” a Linuxban meghatározott karakterek mögé tűzzük. A helyzet az, hogy a Linux korábban „csak a móka kedvéért” volt. De most elsősorban pénzkereső gépezet. Minden lehetségesre készültek. Például nagyon nehéz jó szoftverterméket létrehozni, de az okos „fejlesztők” már rég rájöttek, hogy egyáltalán nem kell erőlködni: sikeresen el lehet adni nem létező szoftvereket, amelyeket mindenféle nyilvánosság előtt bejelentettek és népszerűsítettek. események - a lényeg az, hogy a bemutató diák több „funkciót” tartalmazzon.

A fájlrendszerek erre tökéletesek, mert az eredményről tíz évig nyugodtan alkudhat. Nos, ha valaki később panaszkodik ennek az eredménynek a hiányára, akkor egyszerűen nem ért semmit a fájlrendszerekből! Ez egy pénzügyi piramisra emlékeztet: a csúcson azok a kalandorok állnak, akik elindították ezt a zűrzavart, és azok a kevesek, akiknek „szerencséjük volt”: „kivonták az osztalékot”, azaz. pénzt kapott fejlesztésre, jól fizetett menedzser állást kapott, konferenciákon „megjelent” stb.

Következnek azok, akik „szerencsétlenek”: veszteségeket számolnak, kezelik a használhatatlan szoftvertermékek gyártásba kerülésének következményeit stb. Sokkal több van belőlük. Nos, a piramis tövében a fejlesztők hatalmas tömege „fűrészel” haszontalan kódot. Ők a legnagyobb vesztesek, mert az elvesztegetett időt nem lehet visszaadni. Az ilyen piramisok rendkívül hasznosak Torvalds és társai számára. És minél több ilyen piramis, annál jobb nekik. Az ilyen piramisok táplálásához bármit be lehet venni a magba. Nyilvánosan persze ennek az ellenkezőjét mondják. De nem szavak, hanem tettek alapján ítélek.

Tehát „a fájlrendszerek jövője Linuxban” egy újabb nagy népszerűségnek örvendő, de alig használható szoftver. A Btrfs után nagy valószínűséggel egy ilyen „jövő” helyét a Bcachefs veszi át, ami újabb kísérlet a Linux blokkrétegének átlépésére egy fájlrendszerrel (a rossz példa ragályos). És ami jellemző: ugyanazok a problémák vannak, mint a Btrfs-ben. Sokáig gyanakodtam erre, aztán valahogy nem tudtam ellenállni, és belenéztem a kódba - ez igaz!

A Bcachefs és a Btrfs szerzői az FS létrehozásakor aktívan használták mások forrásait, keveset értenek róluk. A helyzet nagyon emlékeztet a gyerekjátékra, az „elromlott telefonra”. És nagyjából el tudom képzelni, hogy ez a kód hogyan kerül be a kernelbe. Valójában senki nem fogja látni a „gereblyéket” (később mindenki rá fog lépni). A kód stílusával kapcsolatos számos civakodás, nem létező jogsértések vádja, stb. után következtetéseket vonunk le a szerző „hűségéről”, arról, hogy mennyire „kommunikál” más fejlesztőkkel, és mindez mennyire sikeres. majd eladják vállalatoknak.

A végeredmény senkit nem fog érdekelni. Húsz éve talán még érdekelt volna, de most másképp hangzanak el a kérdések: sikerül-e ezt úgy előmozdítani, hogy a következő tíz éven belül bizonyos embereket elhelyezzenek. És sajnos a végeredményen nem szokás csodálkozni.

Általában azt javaslom, hogy ne kezdje el újra feltalálni a fájlrendszert a semmiből. Mert még jelentős pénzügyi befektetések sem lesznek elegendőek ahhoz, hogy tíz év múlva valami versenyképes legyen. Természetesen komoly projektekről beszélek, és nem azokról, amelyeket a rendszermagba szándékoznak „benyomni”. Tehát az önkifejezés hatékonyabb módja, ha csatlakozunk a valódi fejlesztésekhez, mint mi. Ezt persze nem könnyű megtenni – de ez minden magas szintű projekt esetében így van.

Először is önállóan kell leküzdenie az általam kínált problémát. Ezt követően, meggyőződve szándékod komolyságáról, elkezdek segíteni. Hagyományosan csak saját fejlesztéseket használunk. Ez alól kivételt képeznek a tömörítési algoritmusok és néhány hash függvény. Nem küldünk fejlesztőket konferenciákra, és akkor nem ülünk és nem kombináljuk mások ötleteit ("talán mi lesz"), ahogy az a legtöbb startupnál megszokott.

Minden algoritmust mi magunk fejlesztünk. Jelenleg az adattárolás-tudomány algebrai és kombinatorikai vonatkozásai érdekelnek. Különösen véges mezők, aszimptotika, egyenlőtlenségek bizonyítása. A közönséges programozóknak is van dolguk, de azonnal figyelmeztetnem kell: minden olyan javaslatot, hogy „nézzen egy másik FS-t, és tegye ugyanezt”, figyelmen kívül hagyjuk. A Linux-szal VFS-en keresztüli szorosabb integrációt célzó javítások is oda kerülnek majd.

Tehát nincs gereblyénk, de megértjük, hova kell mozdulnunk, és bízunk benne, hogy ez az irány a helyes. Ez a megértés nem a mennyből jött manna formájában. Hadd emlékeztesselek arra, hogy 29 éves fejlesztési tapasztalat áll mögöttünk, két, a semmiből megírt fájlrendszer. És ugyanennyi adat-helyreállító segédprogram. És ez nagyon sok!

Forrás: opennet.ru