Është publikuar intervista e dytë me Eduard Shishkin, zhvillues i sistemit të skedarëve Reiser4.
Për të filluar, kujtojini lexuesit se ku dhe për kë punoni.
Unë punoj si arkitekt kryesor i ruajtjes në Huawei Technologies, Qendra Kërkimore Gjermane. Në departamentin e virtualizimit merrem me aspekte të ndryshme të ruajtjes së të dhënave. Aktivitetet e mia nuk lidhen me një sistem operativ specifik.
A jeni duke u angazhuar aktualisht në degën kryesore të kernelit?
Shumë rrallë, dhe vetëm nëse punëdhënësi im e kërkon atë. Herën e fundit ishte rreth tre vjet më parë, dërgova arna për të rritur xhiron e ruajtjes së ndarë në host duke përdorur protokollin 9p (një emër tjetër për këtë biznes është VirtFS). Këtu duhet bërë një shënim i rëndësishëm: megjithëse kam punuar me Linux për një kohë të gjatë, nuk kam qenë kurrë adhurues i tij, domethënë "marr frymë në mënyrë të barabartë", si me çdo gjë tjetër. Në veçanti, nëse vërej një të metë, mund ta vë në dukje maksimumi një herë. Dhe në mënyrë që të mund të ndiqni dikë dhe ta bindni - kjo nuk do të ndodhë.
Mbaj mend herën e fundit, dhjetë vjet më parë, ju ishit mjaft kritik ndaj stilit të zhvillimit të kernelit. Nga këndvështrimi juaj (ose ndoshta i korporatës), a ka ndryshuar diçka, a është bërë komuniteti më i përgjegjshëm apo jo? Nëse jo, kush mendoni se është fajtor?
Unë kurrë nuk kam parë ndonjë ndryshim për mirë. Problemi kryesor i komunitetit është zëvendësimi i shkencës me teknologjitë politike, marrëdhëniet personale, opinioni i shumicës, populizmi, këshillat nga "zërat e brendshëm", kompromisi i kalbur, gjithçka tjetër përveç shkencës. Shkenca kompjuterike, çfarëdo që mund të thuhet, është para së gjithash një shkencë ekzakte. Dhe nëse dikush fillon të shpallë vlerën e tij për 2x2, ndryshe nga 4, nën flamurin "Linux way" ose nën ndonjë flamur tjetër, atëherë kjo nuk ka gjasa të sjellë asgjë tjetër përveç dëmit.
Të gjitha telashet janë kryesisht për shkak të paaftësisë dhe mungesës së edukimit të atyre që marrin vendime. Nëse një menaxher është i paaftë, ai nuk është në gjendje të marrë një vendim objektiv dhe adekuat. Nëse është edhe i pakulturuar, nuk arrin të gjejë një specialist kompetent që do t'i japë këshillën e duhur. Me një probabilitet të lartë, zgjedhja do të bjerë mbi një mashtrues që thotë "gjëra në dukje të sakta". Një mjedis i korruptuar zhvillohet gjithmonë rreth liderëve të vetmuar të paaftë. Për më tepër, historia nuk njeh përjashtime në këtë drejtim dhe komuniteti është konfirmimi më i qartë i kësaj.
Si e vlerësoni progresin në zhvillimin e Btrfs? A i shpëtoi kjo FS sëmundjet e fëmijërisë? Si e poziciononi atë për veten tuaj - si një FS "për shtëpi" apo edhe për përdorim të korporatës?
Nuk e hoqa qafe. Gjithçka që përmenda 11 vjet më parë është ende aktuale sot. Një nga problemet me Btrfs që e bën atë të papërshtatshëm për nevoja serioze është problemi i hapësirës së lirë. Nuk po flas as për faktin që përdoruesit i kërkohet të vrapojë në dyqan për një disk të ri në situata kur çdo FS tjetër do të shfaqte shumë hapësirë të lirë në ndarje. Pamundësia për të përfunduar një operacion në një vëllim logjik për shkak të mungesës së hapësirës së lirë nuk është gjithashtu gjëja më e keqe. Gjëja më e keqe është se një përdorues i paprivilegjuar pothuajse gjithmonë, mund të anashkalojë çdo kuotë të diskut, t'i privojë të gjithëve hapësirën e lirë në një kohë mjaft të shkurtër.
Duket kështu (e testuar për kernel Linux 5.12). Një skript lëshohet në një sistem të sapo instaluar, i cili në një lak krijon skedarë me emra të caktuar në direktorinë kryesore, u shkruan të dhëna me zhvendosje të caktuara dhe më pas i fshin këta skedarë. Pas një minutë të ekzekutimit të këtij skenari, asgjë e pazakontë nuk ndodh. Pas pesë minutash, pjesa e hapësirës së zënë në ndarje rritet pak. Pas dy deri në tre orë arrin në 50% (me një vlerë fillestare prej 15%). Dhe pas pesë ose gjashtë orësh punë, skenari rrëzohet me gabimin "nuk ka hapësirë të lirë në ndarje". Pas kësaj, nuk jeni më në gjendje të shkruani as një skedar 4K në ndarjen tuaj.
Ndodh një situatë interesante: përfunduat duke mos shkruar asgjë në ndarje dhe e gjithë hapësira e lirë (rreth 85%) u zhduk diku. Analiza e një seksioni që i nënshtrohet një sulmi të tillë do të zbulojë shumë nyje pemësh që përmbajnë vetëm një artikull (një objekt i pajisur me një çelës), me madhësi disa bajt. Kjo do të thotë, përmbajtja që më parë zinte 15% të hapësirës së diskut doli të ishte "e lyer" në mënyrë të barabartë në të gjithë ndarjen, në mënyrë që të mos kishte ku të shkruante një skedar të ri, sepse çelësi i tij është më i madh se të gjithë ekzistuesit, dhe pa pagesë. blloqet në ndarje kanë mbaruar.
Për më tepër, e gjithë kjo ndodh tashmë në konfigurimin bazë të Btrfs (pa asnjë fotografi, nënvëllim, etj.), dhe nuk ka rëndësi se si vendosni të ruani trupat e skedarëve në atë FS (si "fragmente" në një pemë ose si shtrirje e blloqeve të paformatuara) - rezultati përfundimtar do të jetë i njëjtë.
Ju nuk do të jeni në gjendje t'i nënshtroni sistemet e tjera të skedarëve në rrjedhën e sipërme ndaj një sulmi të tillë (pa marrë parasysh se çfarë ju thonë). Unë e shpjegova shkakun e problemit shumë kohë më parë: ky është një perversion i plotë i konceptit të pemës B në Btrfs, i cili bën të mundur që ajo të degjenerohet spontanisht ose qëllimisht. Në veçanti, nën ngarkesa të caktuara, sistemi juaj i skedarëve do të "shbëhet" vazhdimisht gjatë funksionimit vetë, pa ndihmë nga jashtë. Është e qartë se të gjitha llojet e proceseve "shtypëse" të sfondit do të kursejnë ditën vetëm në desktopët individualë.
Në serverët kolektivë, një sulmues gjithmonë do të jetë në gjendje t'i "përparojë" ata. Administratori i sistemit as nuk do të jetë në gjendje të përcaktojë se kush e ngacmoi saktësisht. Mënyra më e shpejtë për të rregulluar këtë problem në Btrfs është të rivendosni strukturën e një peme të rregullt B, d.m.th. ridizajnimi i formatit të diskut dhe rishkrimi i pjesëve të rëndësishme të kodit Btrfs. Kjo do të zgjasë 8-10 vjet, duke përfshirë korrigjimin, me kusht që zhvilluesit të ndiqnin me përpikëri artikujt origjinalë mbi algoritmet dhe strukturat përkatëse të të dhënave dhe të mos luanin lojën "telefon i prishur", siç është zakon (dhe inkurajohet) në "Linux". mënyrë”.
Këtu duhet të shtojmë edhe kohën e nevojshme që zhvilluesit të kuptojnë të gjitha këto. Këtu bëhet më e vështirë. Gjithsesi, 10 vjet nuk u mjaftuan për ta kuptuar. Epo, deri atëherë nuk mund të shpresoni për një mrekulli. Nuk do të ndodhë në formën e një opsioni montimi "për të cilin ju dhe unë nuk dinim", ose në formën e një patch që është "thjesht një çështje biznesi" për t'u përgatitur. Për çdo “rregullim” të tillë të nxituar do të paraqes një skenar të ri degjenerimi. B-pemët janë një nga temat e mia të preferuara dhe më duhet të them që këto struktura nuk tolerojnë liri me vetveten!
Si t'i pozicionoj Btrfs për veten time? Si diçka që absolutisht nuk mund të quhet një sistem skedar, e lëre më të përdoret. Sepse, sipas përkufizimit, FS është një nënsistem OS përgjegjës për menaxhimin efektiv të burimit të "hapësirës së diskut", gjë që nuk e shohim në rastin e Btrfs. Epo, imagjinoni që keni ardhur në dyqan për të blerë një orë që të mos vonoheni në punë dhe në vend të një ore ju kanë shitur një skarë elektrike me kohëmatës për maksimum 30 minuta. Pra, situata me Btrfs është edhe më e keqe.
Duke parë listat e postimeve, shpesh ndeshem me deklaratën se menaxhimi efektiv i hapësirës në disk nuk është më i rëndësishëm për shkak të çmimit të lirë të disqeve. Kjo është absurditet i plotë. Pa një menaxher efektiv të hapësirës në disk, OS do të bëhet i prekshëm dhe i papërdorshëm. Pavarësisht nga kapaciteti i disqeve në kompjuterin tuaj.
Do të doja të kërkoja koment për ndërprerjen e mbështetjes së Btrfs në RHEL.
Nuk ka asgjë të veçantë për të komentuar këtu, gjithçka është shumë e qartë. Ata gjithashtu e kishin atë si një "parapamje teknologjike". Pra, nuk e kalova këtë "parapamje". Mos lejoni që kjo etiketë të varet përgjithmonë! Por ata nuk mund të lançojnë një produkt të metë nën-dizajn me mbështetje të plotë. RHEL është një ndërmarrje, domethënë marrëdhënie të përcaktuara mall-para. Red Hat nuk mund të ngacmojë përdoruesit siç bëjnë në listën e postimeve të Btrfs. Vetëm imagjinoni situatën: një klient që pagoi paratë e tij të fituara me vështirësi për diskun dhe gjithashtu ju për mbështetje, dëshiron të kuptojë se ku i ka shkuar hapësira në disk pasi nuk ka shkruar asgjë. Çfarë do t'i përgjigjesh atij për këtë?
Me tutje. Klientët e Red Hat përfshijnë banka dhe bursa të mëdha të njohura. Imagjinoni se çfarë do të ndodhte nëse ata do t'i nënshtroheshin sulmeve DoS bazuar në cenueshmërinë e përmendur në Btrfs. Kush mendoni se është përgjegjës për këtë? Atyre që do të drejtojnë gishtin në vijën e licencës GPL, ku shkruhet se autori nuk mban përgjegjësi për asgjë, do t'u them menjëherë: "fshihe!" Red Hat do të përgjigjet, dhe në një mënyrë të tillë që nuk do të duket e mjaftueshme! Por e di që Red Hat nuk po përballet me këtë lloj problemi, duke pasur parasysh ekipin e tyre veçanërisht të fortë të inxhinierëve të QA me të cilët pata mundësinë të punoja ngushtë në kohën time.
Pse disa kompani vazhdojnë të mbështesin Btrfs në produktet e tyre të ndërmarrjes?
Ju lutemi vini re se prefiksi "ndërmarrje" në emrin e produktit nuk do të thotë shumë. Ndërmarrja është një masë përgjegjësie e përfshirë në marrëdhënien kontraktuale me klientin. Unë njoh vetëm një ndërmarrje të bazuar në GNU/Linux - RHEL. Çdo gjë tjetër, nga këndvështrimi im, paraqitet vetëm si ndërmarrje, por nuk është një. Dhe së fundi, nëse ka një kërkesë për diçka, atëherë do të ketë gjithmonë një ofertë (në rastin tonë, kjo është "mbështetja" e përmendur). Ka kërkesë për absolutisht gjithçka, përfshirë. dhe softuer të papërdorshëm. Se si formohet një kërkesë e tillë dhe kush e nxit atë është një temë tjetër.
Pra, nuk do të nxitoja në ndonjë përfundim pasi Facebook-u përflitet se ka vendosur Btrfs në serverët e tij. Për më tepër, unë do të rekomandoja mbajtjen e fshehtë të adresave të atyre serverëve për arsyet e mësipërme.
Pse është bërë kaq shumë përpjekje për të pastruar kodin XFS kohët e fundit? Në fund të fundit, fillimisht ky është një sistem skedar i palëve të treta, dhe ext4 ka qenë i qëndrueshëm për një kohë të gjatë dhe ka vazhdimësi nga versionet e mëparshme po aq të qëndrueshme. Çfarë interesi ka Red Hat në XFS? A ka kuptim që në mënyrë aktive të zhvillohen dy sisteme skedarësh që janë të ngjashëm në qëllim - ext4 dhe XFS?
Nuk e mbaj mend se çfarë e motivoi këtë. Ka shumë mundësi që iniciativa të ketë ardhur nga klientët e Red Hat. Mbaj mend që u kryen kërkime të këtij lloji: në disa sisteme skedarësh nga rrjedha e sipërme, u krijuan një numër gjigant objektesh në disqet e nivelit të lartë të gjeneratës së re. Sipas rezultateve, XFS u soll më mirë se ext4. Kështu ata filluan ta promovojnë atë si më premtuesin. Në çdo rast, këtu nuk do të kërkoja asgjë të bujshme.
Për mua është sikur të kenë zëvendësuar një fëndyell me sapun. Nuk ka asnjë pikë në zhvillimin e ext4 dhe XFS. Të dyja paralelisht dhe ndonjë prej tyre për të zgjedhur. Asgjë e mirë nuk do të vijë nga kjo. Edhe pse, në natyrë shpesh ka situata kur ka shumë potencial për rritje, por nuk ka vend për t'u rritur. Në këtë rast, lindin rritje të ndryshme të çuditshme të shëmtuara, të cilave të gjithë tregojnë gishtin ("Oh, shikoni, çfarë nuk do të shihni në këtë jetë!").
A mendoni se çështja e shkeljes së shtresës është zgjidhur (në një kuptim negativ) me ardhjen e funksioneve të enkriptimit në ext4, F2FS (për të mos përmendur RAID në Btrfs)?
Në përgjithësi, futja e çdo niveli dhe marrja e një vendimi për mosshkeljen e tyre është zakonisht çështje politike dhe nuk marr përsipër të komentoj asgjë këtu. Aspektet objektive të shkeljes së shtresës janë me pak interes për këdo, por ne mund t'i konsiderojmë disa prej tyre duke përdorur shembullin e shkeljes "nga lart", domethënë zbatimin në FS të funksionalitetit që ekziston tashmë në shtresën e bllokut. Një "shkelje" e tillë justifikohet vetëm me përjashtime të rralla. Për çdo rast të tillë, së pari duhet të provoni dy gjëra: se është vërtet e nevojshme dhe se dizajni i sistemit nuk do të dëmtohet duke vepruar kështu.
Për shembull, pasqyrimi, i cili tradicionalisht ka qenë një aktivitet për shtresën e bllokut, ka kuptim të zbatohet në nivelin e sistemit të skedarëve. Për arsye të ndryshme. Për shembull, prishja "e heshtur" e të dhënave (kalbja e bitit) ndodh në disqet e diskut. Kjo është kur pajisja funksionon siç duhet, por të dhënat e bllokut dëmtohen papritur nën ndikimin e një kuantike gama të fortë të emetuar nga një kuazar i largët, etj. Gjëja më e keqe është nëse ky bllok rezulton të jetë një bllok i sistemit FS (superblloku, blloku bitmap, nyja e pemës së ruajtjes, etj.), sepse kjo me siguri do të çojë në një panik të kernelit.
Ju lutemi vini re se pasqyrat e ofruara nga shtresa e bllokut (të ashtuquajturat RAID 1) nuk do t'ju shpëtojnë nga ky problem. Epo, me të vërtetë: dikush duhet të kontrollojë shumat e kontrollit dhe të lexojë kopjen në rast të dështimit? Për më tepër, ka kuptim të pasqyroni jo vetëm gjithçka, por vetëm metadatat. Disa të dhëna të rëndësishme (për shembull, skedarët e ekzekutueshëm të aplikacioneve kritike) mund të ruhen si meta të dhëna. Në këtë rast, ata marrin të njëjtat garanci sigurie. Ka kuptim t'i besojmë mbrojtjen e të dhënave të mbetura nënsistemeve të tjera (ndoshta edhe aplikacioneve të përdoruesve) - ne kemi siguruar të gjitha kushtet e nevojshme për këtë.
Pasqyra të tilla "ekonomike" kanë të drejtë të ekzistojnë dhe ato mund të organizohen në mënyrë efektive vetëm në nivelin e sistemit të skedarëve. Përndryshe, shkelja e shtresimit është duke rrëmuar një nënsistem me kod të dyfishuar për hir të disa përfitimeve mikroskopike. Një shembull i mrekullueshëm i kësaj është zbatimi i RAID-5 duke përdorur FS. Zgjidhje të tilla (veta RAID / LVM në sistemin e skedarëve) e vrasin këtë të fundit në aspektin arkitektonik. Duhet të theksohet gjithashtu këtu se shkelja e shtresimit është "vënë në qarkullim" nga lloje të ndryshme mashtruesish të marketingut. Në mungesë të ndonjë ideje, funksionaliteti që është zbatuar prej kohësh në nivelet fqinje i shtohet nënsistemeve, ky paraqitet si një veçori e re jashtëzakonisht e dobishme dhe shtyhet në mënyrë aktive.
Reiser4 u akuzua për shkelje të niveleve "nga poshtë". Bazuar në faktin se sistemi i skedarëve nuk është monolit, si gjithë të tjerët, por modular, u bë një supozim i pabazuar se ai bën atë që duhet të bëjë niveli i mësipërm (VFS).
A është e mundur të flitet për vdekjen e ReiserFS v3.6 dhe, për shembull, JFS? Kohët e fundit ata nuk kanë marrë pothuajse asnjë vëmendje në thelb. A janë ato të vjetruara?
Këtu duhet të përcaktojmë se çfarë do të thotë vdekja e një produkti softuer. Nga njëra anë, ato përdoren me sukses (në fund të fundit për këtë janë krijuar), që do të thotë se ata jetojnë. Nga ana tjetër, nuk mund të flas për JFS (nuk di shumë), por ReiserFS (v3) është shumë e vështirë për t'u përshtatur me tendencat e reja (e testuar në praktikë). Kjo do të thotë që në të ardhmen zhvilluesit do t'i kushtojnë vëmendje jo asaj, por atyre që janë më të lehtë për t'u përshtatur. Nga kjo anë del se, mjerisht, ka vdekur në aspektin arkitektonik. Unë nuk do ta manipuloja fare konceptin e "të vjetëruar moralisht". Zbatohet mirë, për shembull, për një gardërobë, por jo për produktet softuerike. Ekziston një koncept i inferioritetit dhe epërsisë në diçka. Mund të them absolutisht se ReserFS v3 tani është inferior ndaj Reiser4 në gjithçka, por në disa lloje të ngarkesës së punës është më i lartë se të gjitha FS-të e tjera në rrjedhën e sipërme.
A dini për zhvillimin e FS Tux3 dhe HAMMER/HAMMER2 (FS për DragonFly BSD)?
Po, ne e dimë. Në Tux3 dikur isha i interesuar për teknologjinë e fotografive të tyre (të ashtuquajturit "treguesit e versionit"), por në Reiser4 me shumë mundësi do të shkojmë në një rrugë tjetër. Unë kam qenë duke menduar për mbështetjen e fotografive për një kohë të gjatë dhe nuk kam vendosur ende se si t'i zbatoj ato për vëllime të thjeshta Reiser4. Fakti është se teknika e re e referencës "dembele" e propozuar nga Ohad Rodeh funksionon vetëm për pemët B. Nuk i kemi. Për ato struktura të dhënash që përdoren në Reiesr4, numëruesit "dembelë" nuk janë përcaktuar - për t'i prezantuar ato, është e nevojshme të zgjidhen disa probleme algoritmike, të cilat askush nuk i ka marrë ende.
Sipas HAMMER: Kam lexuar një artikull nga krijuesi. Jo i interesuar. Përsëri, B-pemë. Kjo strukturë e të dhënave është pashpresë e vjetëruar. E kemi braktisur në shekullin e kaluar.
Si e vlerësoni kërkesën në rritje për FS të grupeve të rrjetit si CephFS/GlusterFS/etj? A nënkupton kjo kërkesë një zhvendosje në prioritetet e zhvilluesve drejt FS të rrjetit dhe vëmendje të pamjaftueshme ndaj FS lokale?
Po, një ndryshim i tillë në prioritete ka ndodhur. Zhvillimi i sistemeve lokale të skedarëve ka ngecur. Mjerisht, të bësh diçka domethënëse për vëllimet lokale tani është mjaft e vështirë dhe jo të gjithë mund ta bëjnë atë. Askush nuk dëshiron të investojë në zhvillimin e tyre. Kjo është pothuajse e njëjtë sikur t'i kërkoni një organizate tregtare të ndajë para për kërkime matematikore - pa asnjë entuziazëm ata do t'ju pyesin se si mund të fitoni para në një teoremë të re. Tani një FS lokale është diçka që shfaqet në mënyrë magjike "jashtë kutisë" dhe "duhet të funksionojë gjithmonë", dhe nëse nuk funksionon, shkakton ankesa të pa adresuara si: "Po, çfarë po mendojnë ata!"
Prandaj mungesa e vëmendjes ndaj FS vendore, megjithëse ka ende shumë punë në atë fushë. Dhe po, të gjithë i janë drejtuar ruajtjes së shpërndarë, e cila është ndërtuar në bazë të sistemeve ekzistuese të skedarëve lokalë. Tani është shumë në modë. Shprehja “Big Data” shkakton një adrenalinë për shumë njerëz, duke e shoqëruar atë me konferenca, seminare, paga të mëdha etj.
Sa e arsyeshme është në parim zbatimi i sistemit të skedarëve të rrjetit në hapësirën e kernelit dhe jo në hapësirën e përdoruesit?
Një qasje shumë e arsyeshme që ende nuk është zbatuar askund. Në përgjithësi, pyetja se në çfarë hapësire duhet të zbatohet një sistem skedari rrjeti është një "shpatë me dy tehe". Epo, le të shohim një shembull. Klienti regjistroi të dhëna në një makinë të largët. Ata ranë në cache-in e faqeve të saj në formën e faqeve të pista. Kjo është puna për një sistem skedari të rrjetit "portë të hollë" në hapësirën e kernelit. Atëherë sistemi operativ herët a vonë do t'ju kërkojë t'i shkruani ato faqe në disk për t'i çliruar ato. Pastaj moduli FS i rrjetit të përcjelljes (dërgimit) IO hyn në lojë. Ai përcakton se në cilën makinë serveri (nyje serveri) do të shkojnë këto faqe.
Pastaj grumbulli i rrjetit merr përsipër (dhe, siç e dimë, ai zbatohet në hapësirën e kernelit). Më pas, nyja e serverit merr atë paketë me të dhëna ose metadata dhe udhëzon modulin e ruajtjes së backend (d.m.th., FS-në lokale që operon në hapësirën e kernelit) për të regjistruar të gjitha këto gjëra. Pra, ne e kemi reduktuar pyetjen se ku duhet të funksionojnë modulet "dërgimi" dhe "marrja". Nëse ndonjë prej këtyre moduleve funksionon në hapësirën e përdoruesit, kjo në mënyrë të pashmangshme do të çojë në ndërrimin e kontekstit (për shkak të nevojës për të përdorur shërbimet e kernelit). Numri i ndërprerësve të tillë varet nga detajet e zbatimit.
Nëse ka shumë ndërprerës të tillë, atëherë kapaciteti i ruajtjes (performanca I/O) do të ulet. Nëse ruajtja juaj e backend përbëhet nga disqe të ngadaltë, atëherë nuk do të vini re një rënie të konsiderueshme. Por nëse keni disqe të shpejtë (SSD, NVRAM, etj.), atëherë ndërrimi i kontekstit tashmë bëhet një "blloqe" dhe, duke kursyer në ndërrimin e kontekstit, performanca mund të rritet ndjeshëm. Mënyra standarde për të kursyer para është zhvendosja e moduleve në hapësirën e kernelit. Për shembull, ne zbuluam se lëvizja e serverit 9p nga QEMU në kernel në makinën pritës çon në një rritje të trefishtë të performancës së VirtFS.
Kjo, natyrisht, nuk është një FS e rrjetit, por pasqyron plotësisht thelbin e gjërave. Ana negative e këtij optimizimi janë çështjet e transportueshmërisë. Për disa, kjo e fundit mund të jetë kritike. Për shembull, GlusterFS nuk ka fare module në kernel. Falë kësaj, ai tani funksionon në shumë platforma, duke përfshirë NetBSD.
Çfarë konceptesh mund të huazojnë FS-të lokale nga ato të rrjetit dhe anasjelltas?
Në ditët e sotme, FS-të e rrjetit, si rregull, kanë shtesa mbi FS-të lokale, kështu që nuk e kuptoj fare se si mund të huazoni diçka nga kjo e fundit. Epo, me të vërtetë, le të marrim parasysh një kompani me 4 punonjës, në të cilën secili bën punën e vet: njëri shpërndan, tjetri dërgon, i treti merr, i katërti ruan. Dhe pyetja, çfarë mund të marrë hua kompania nga punonjësi i saj që e ruan atë, tingëllon disi e gabuar (ajo tashmë ka atë që mund të kishte marrë hua prej tij për një kohë të gjatë).
Por FS-të lokale kanë shumë për të mësuar nga ato të rrjetit. Së pari, duhet të mësoni prej tyre se si të grumbulloni vëllime logjike në një nivel të lartë. Tani e ashtuquajtura Sistemet lokale të skedarëve "të avancuar" grumbullojnë vëllime logjike ekskluzivisht duke përdorur teknologjinë "pajisje virtuale" të huazuar nga LVM (e njëjta shkelje e shtresimit infektiv që u zbatua për herë të parë në ZFS). Me fjalë të tjera, përkthimi i adresave virtuale (numrat e bllokut) në ato reale dhe mbrapa ndodh në një nivel të ulët (d.m.th., pasi sistemi i skedarëve ka lëshuar një kërkesë I/O).
Ju lutemi vini re se shtimi dhe heqja e pajisjeve në vëllime logjike (jo pasqyra) të rregulluara në shtresën e bllokut çon në probleme për të cilat furnizuesit e "veçorive" të tilla heshtin në mënyrë modeste. E kam fjalën për fragmentimin në pajisje reale, të cilat mund të arrijnë vlera monstruoze, ndërsa në një pajisje virtuale gjithçka është në rregull. Sidoqoftë, pak njerëz janë të interesuar për pajisjet virtuale: të gjithë janë të interesuar për atë që po ndodh në pajisjet tuaja reale. Por FS të ngjashme me ZFS (si dhe çdo FS në lidhje me LVM) funksionojnë vetëm me pajisjet e diskut virtual (ndani adresat e diskut virtual nga ato të lira, defragmentoni këto pajisje virtuale, etj.). Dhe ata nuk e kanë idenë se çfarë po ndodh në pajisjet reale!
Tani imagjinoni që keni zero fragmentim në pajisjen virtuale (d.m.th., ju keni vetëm një shtrirje gjigante që jeton atje), shtoni një disk në vëllimin tuaj logjik dhe më pas hiqni një disk tjetër të rastësishëm nga vëllimi juaj logjik dhe më pas ribalanconi. Dhe kaq shumë herë. Nuk është e vështirë të imagjinohet që në pajisjen virtuale do të keni ende të njëjtën masë jetese, por në pajisjet reale nuk do të shihni asgjë të mirë.
Gjëja më e keqe është se ju nuk jeni në gjendje ta korrigjoni këtë situatë! E vetmja gjë që mund të bëni këtu është të kërkoni nga sistemi i skedarëve të defragmentojë pajisjen virtuale. Por ajo do t'ju thotë se gjithçka është e shkëlqyeshme atje - ka vetëm një masë, fragmentimi është zero dhe nuk mund të jetë më mirë! Pra, vëllimet logjike të rregulluara në nivelin e bllokut nuk janë të destinuara për shtim/heqje të përsëritur të pajisjeve. Në një mënyrë të mirë, ju duhet vetëm të grumbulloni një vëllim logjik në nivelin e bllokut një herë, t'ia jepni sistemit të skedarëve dhe më pas të mos bëni asgjë tjetër me të.
Për më tepër, kombinimi i nënsistemeve të pavarura FS+LVM nuk lejon marrjen parasysh të natyrës së ndryshme të disqeve nga të cilat grumbullohen vëllimet logjike. Në të vërtetë, supozoni se keni mbledhur një vëllim logjik nga HDD dhe pajisjet e gjendjes së ngurtë. Por atëherë e para do të kërkojë defragmentim, dhe e dyta jo. Për këtë të fundit, duhet të lëshoni kërkesa për hedhjen poshtë, por për të parën jo, etj. Sidoqoftë, në këtë kombinim është mjaft e vështirë të demonstrohet një selektivitet i tillë.
Vini re se pas krijimit të LVM-së tuaj në sistemin e skedarëve, situata nuk përmirësohet shumë. Për më tepër, duke bërë këtë ju në fakt i jepni fund perspektivës për ta përmirësuar atë ndonjëherë në të ardhmen. Kjo është shumë e keqe. Lloje të ndryshme disqet mund të jetojnë në të njëjtën makinë. Dhe nëse sistemi i skedarëve nuk bën dallimin midis tyre, atëherë kush do ta bëjë?
Një problem tjetër qëndron në pritje për të ashtuquajturat. Sistemet e skedarëve "Write-Anywhere" (kjo përfshin gjithashtu Reiser4, nëse keni specifikuar modelin e duhur transaksional gjatë montimit). Sisteme të tilla skedarësh duhet të ofrojnë mjete defragmentimi që janë të paprecedentë në fuqinë e tyre. Dhe menaxheri i vëllimit të nivelit të ulët nuk ndihmon këtu, por vetëm pengon. Fakti është se me një menaxher të tillë, FS juaj do të ruajë një hartë të blloqeve falas të vetëm një pajisjeje - një virtuale. Prandaj, mund të defragmentoni vetëm një pajisje virtuale. Kjo do të thotë që defragmentuesi juaj do të funksionojë për një kohë të gjatë, në një hapësirë të madhe të vetme adresash virtuale.
Dhe nëse keni shumë përdorues që bëjnë mbishkrime të rastësishme, atëherë efekti i dobishëm i një defragmentuesi të tillë do të reduktohet në zero. Sistemi juaj në mënyrë të pashmangshme do të fillojë të ngadalësohet dhe do t'ju duhet vetëm të palosni duart përpara diagnozës zhgënjyese "dizajn i thyer". Disa defragmentues që funksionojnë në të njëjtën hapësirë adresash do të ndërhyjnë vetëm me njëri-tjetrin. Është një çështje krejtësisht e ndryshme nëse mbani hartën tuaj të blloqeve të lira për çdo pajisje reale. Kjo do të paralelizojë në mënyrë efektive procesin e defragmentimit.
Por kjo mund të bëhet vetëm nëse keni një menaxher të vëllimit logjik të nivelit të lartë. Sistemet lokale të skedarëve me menaxherë të tillë nuk ekzistonin më parë (të paktën, unë nuk di për ta). Vetëm sistemet e skedarëve të rrjetit (për shembull GlusterFS) kishin menaxherë të tillë. Një shembull tjetër shumë i rëndësishëm është mjeti i kontrollit të integritetit të vëllimit (fsck). Nëse ruani hartën tuaj të pavarur të blloqeve të lira për çdo nënvëllim, atëherë procedura për kontrollimin e një vëllimi logjik mund të paralelizohet në mënyrë efektive. Me fjalë të tjera, vëllimet logjike me menaxherë të nivelit të lartë shkallëzohen më mirë.
Përveç kësaj, me menaxherët e vëllimit të nivelit të ulët nuk do të jeni në gjendje të organizoni fotografi të plota. Me sisteme skedarësh të ngjashëm me LVM dhe ZFS, mund të bëni vetëm fotografi lokale, por jo fotografi globale. Fotot e çastit lokal ju lejojnë të ktheni në çast vetëm operacionet e rregullta të skedarëve. Dhe askush atje nuk do të rikthejë operacionet me vëllime logjike (shtimi/heqja e pajisjeve). Le ta shohim këtë me një shembull. Në një moment në kohë, kur keni një vëllim logjik të dy pajisjeve A dhe B që përmbajnë 100 skedarë, ju merrni një fotografi të sistemit S dhe më pas krijoni njëqind skedarë të tjerë.
Pas kësaj, ju shtoni pajisjen C në volumin tuaj dhe në fund ktheni sistemin tuaj në fotografinë e çastit S. Pyetje: Sa skedarë dhe pajisje përmban vëllimi juaj logjik pas rikthimit në S? Do të ketë 100 skedarë, siç mund ta keni marrë me mend, por do të ketë 3 pajisje - këto janë të njëjtat pajisje A, B dhe C, megjithëse në kohën kur u krijua fotografia kishte vetëm dy pajisje në sistem (A dhe B ). Operacioni i shtimit të pajisjes C nuk u kthye mbrapsht dhe nëse tani e hiqni pajisjen C nga kompjuteri, ajo do të korruptojë të dhënat tuaja, kështu që përpara se t'i fshini do t'ju duhet fillimisht të kryeni një operacion të shtrenjtë për të hequr pajisjen nga vëllimi logjik i ribalancimit, i cili do të shpërndajë të gjitha të dhënat nga pajisja C te pajisjet A dhe B. Por nëse FS-ja juaj mbështet pamjet globale, një ribalancim i tillë nuk do të kërkohet dhe pas një rikthimi të menjëhershëm në S, mund ta hiqni pa rrezik pajisjen C nga kompjuteri.
Pra, fotografitë globale janë të mira sepse ju lejojnë të shmangni heqjen (shtimin) e kushtueshëm të një pajisjeje nga një vëllim logjik (në një vëllim logjik) me një sasi të madhe të dhënash (natyrisht, nëse mbani mend të "marrëveshni" sistemin tuaj në kohën e duhur). Më lejoni t'ju kujtoj se krijimi i fotografive dhe kthimi i sistemit të skedarëve në to janë operacione të menjëhershme. Mund të lindë pyetja: si është e mundur që të rikthehet në çast një operacion në një vëllim logjik që ju mori tre ditë? Por është e mundur! Me kusht që sistemi juaj i skedarëve të jetë projektuar saktë. Ideja e "fotografive të tilla 3D" më erdhi tre vjet më parë, dhe vitin e kaluar e patenta këtë teknikë.
Gjëja tjetër që FS-të lokale duhet të mësojnë nga ato të rrjetit është ruajtja e meta të dhënave në pajisje të veçanta në të njëjtën mënyrë që FS-të e rrjetit i ruajnë ato në makina të veçanta (të ashtuquajturit serverë metadata). Ka aplikacione që punojnë kryesisht me metadata dhe këto aplikacione mund të përshpejtohen shumë duke i vendosur meta të dhënat në pajisje të shtrenjta ruajtjeje me performancë të lartë. Me kombinimin FS+LVM, nuk do të jeni në gjendje të demonstroni një përzgjedhje të tillë: LVM nuk e di se çfarë është në bllokun që i keni kaluar (të dhënat atje ose meta të dhënat).
Nuk do të përfitoni shumë nga zbatimi i LVM-së tuaj të nivelit të ulët në FS në krahasim me kombinimin FS+LVM, por ajo që mund të bëni shumë mirë është të rrëmoni FS-në në mënyrë që më vonë të bëhet e pamundur të punohet me kodin e tij. ZFS dhe Btrfs, të cilat nxituan me pajisjet virtuale, janë të gjithë shembuj të qartë se si shkelja e shtresave e vret sistemin në aspektin arkitektonik Pra, pse jam gjithë kjo? Për më tepër, nuk ka nevojë të ndërtoni LVM-në tuaj të nivelit të ulët në sistemin e skedarëve. Në vend të kësaj, ju duhet të grumbulloni pajisjet në vëllime logjike në një nivel të lartë, siç bëjnë disa sisteme skedarësh të rrjetit me makina të ndryshme (nyjet e ruajtjes). Vërtetë, ata e bëjnë këtë në mënyrë të neveritshme për shkak të përdorimit të algoritmeve të këqija.
Shembuj të algoritmeve absolutisht të tmerrshme janë përkthyesi DHT në sistemin e skedarëve GlusterFS dhe e ashtuquajtura harta CRUSH në sistemin e skedarëve Ceph. Asnjë nga algoritmet që pashë nuk më kënaqi për sa i përket thjeshtësisë dhe shkallëzueshmërisë së mirë. Kështu që më duhej të kujtoja algjebrën dhe të shpikja gjithçka vetë. Në vitin 2015, ndërsa eksperimentoja me paketat mbi funksionet hash, dola dhe patentova diçka që më përshtatet. Tani mund të them se përpjekja për të vënë në jetë të gjitha këto ishte e suksesshme. Unë nuk shoh ndonjë problem me shkallëzueshmërinë në qasjen e re.
Po, çdo nënvëllim do të kërkojë një strukturë të veçantë, siç është një superbllok në memorie. A është kjo shumë e frikshme? Në përgjithësi, nuk e di se kush do të "ziejë oqeanin" dhe do të krijojë vëllime logjike të qindra mijëra ose më shumë pajisjeve në një makinë lokale. Nëse dikush mund të ma shpjegojë këtë, do të jem shumë mirënjohës. Ndërkohë, për mua kjo është budallallëk marketingu.
Si ndikuan ndryshimet në nënsistemin e pajisjes së bllokut të kernelit (për shembull, shfaqja e blk-mq) në kërkesat për zbatimin e FS?
Nuk patën asnjë ndikim. Nuk e di se çfarë do të ndodhte në shtresën e bllokut që do të bënte të nevojshme hartimin e një FS të ri. Ndërfaqja e ndërveprimit të këtyre nënsistemeve është shumë e dobët. Nga ana e drejtuesit, FS duhet të ndikohet vetëm nga shfaqja e llojeve të reja të disqeve, të cilave do t'u rregullohet fillimisht shtresa e bllokut, dhe më pas FS (për reiser4 kjo do të thotë shfaqjen e shtojcave të reja).
A do të thotë shfaqja e llojeve të reja të mediave (për shembull, SMR, ose prania e kudondodhur e SSD-ve) sfida thelbësisht të reja për hartimin e sistemit të skedarëve?
Po. Dhe këto janë stimuj normalë për zhvillimin e FS. Sfidat mund të jenë të ndryshme dhe krejtësisht të papritura. Për shembull, kam dëgjuar për disqe ku shpejtësia e një operacioni I/O varet shumë nga madhësia e një pjese të të dhënave dhe kompensimi i saj. Në Linux, ku madhësia e bllokut FS nuk mund të kalojë madhësinë e faqes, një disk i tillë nuk do të tregojë aftësitë e tij të plota si parazgjedhje. Sidoqoftë, nëse sistemi juaj i skedarëve është projektuar në mënyrë korrekte, atëherë ka një shans për të përfituar shumë më tepër prej tij.
Sa njerëz po punojnë aktualisht me kodin Reiser4 përveç jush?
Më pak se sa do të doja, por as nuk përjetoj mungesë akute burimesh. Jam më se i kënaqur me ritmin e zhvillimit të Reiser4. Unë nuk do të "ngas kuajt" - kjo nuk është zona e duhur. Këtu, "nëse vozitni më qetë, do të vazhdoni!" Një sistem skedar modern është nënsistemi më kompleks i kernelit, vendimet e gabuara të projektimit të të cilit mund të zhbëjnë vitet e mëvonshme të punës njerëzore.
Duke ofruar vullnetarë për të zbatuar diçka, unë gjithmonë garantoj se përpjekjet me siguri do të çojnë në rezultatin e duhur, i cili mund të jetë i kërkuar për nevoja serioze. Siç e kuptoni, nuk mund të ketë shumë garanci të tilla menjëherë. Në të njëjtën kohë, nuk mund të duroj "figura" që promovojnë paturpësisht "karakteristikat" e softuerit dukshëm të papërdorshëm, duke mashtruar qindra përdorues dhe zhvillues, dhe në të njëjtën kohë ulen dhe buzëqeshin në samitet e kernelit.
A ka shprehur ndonjë kompani gatishmëri për të mbështetur zhvillimin e Reiser4?
Po, ka pasur propozime të tilla, përfshirë. dhe nga një shitës i madh. Por për këtë më duhej të shkoja në një vend tjetër. Fatkeqësisht, nuk jam më 30 vjeç, nuk mund të shkëputem dhe të largohem ashtu që në bilbilin e parë.
Cilat veçori i mungojnë aktualisht Reiser4?
Nuk ka funksion "ridimensioni" për vëllime të thjeshta, të ngjashme me atë që gjendet në ReiserFS(v3). Përveç kësaj, operacionet e skedarëve me flamurin DIRECT_IO nuk do të dëmtonin. Më pas, do të doja të isha në gjendje të veçoja një vëllim në "nënvëllime semantike", të cilat nuk kanë një madhësi fikse dhe që mund të montohen si vëllime të pavarura. Këto probleme janë të mira për fillestarët që duan të provojnë dorën e tyre në "gjënë e vërtetë".
Dhe së fundi, do të doja të kisha vëllime logjike të rrjetit me zbatim dhe administrim të thjeshtë (algoritmet moderne tashmë e lejojnë këtë). Por ajo që Reiser4 definitivisht nuk do të ketë kurrë është RAID-Z, pastrime, cache të hapësirës së lirë, variabla 128-bit dhe marrëzi të tjera marketingu që u ngritën në sfondin e mungesës së ideve midis zhvilluesve të disa sistemeve të skedarëve.
A mund të zbatohet gjithçka që mund të nevojitet nga shtojcat?
Nëse flasim vetëm për ndërfaqet dhe shtojcat (modulet) që i zbatojnë ato, atëherë jo gjithçka. Por nëse futni edhe marrëdhënie në këto ndërfaqe, atëherë, ndër të tjera, do të keni konceptet e polimorfizmave më të larta, me të cilat tashmë mund të përballeni. Imagjinoni që hipotetikisht keni ngrirë një sistem kohëzgjatjeje të orientuar nga objekti, keni ndryshuar vlerën e treguesit të udhëzimit për të treguar një shtesë shtesë që zbaton të njëjtën ndërfaqe X dhe më pas e keni shkrirë sistemin në mënyrë që të vazhdojë të ekzekutohet.
Nëse përdoruesi përfundimtar nuk e vëren një "zëvendësim" të tillë, atëherë themi se sistemi ka polimorfizëm të rendit zero në ndërfaqen X (ose sistemi është heterogjen në ndërfaqen X, që është e njëjta gjë). Nëse tani jo vetëm që keni një grup ndërfaqesh, por keni edhe marrëdhënie mbi to (grafiku i ndërfaqes), atëherë mund të prezantoni polimorfizma të rendit më të lartë, të cilat do të karakterizojnë heterogjenitetin e sistemit tashmë në "lagjen" e çdo ndërfaqeje. Një klasifikim të tillë e kam prezantuar shumë kohë më parë, por, për fat të keq, nuk ka ndodhur kurrë.
Pra, me ndihmën e shtojcave dhe polimorfizmave të tilla më të larta, mund të përshkruani çdo veçori të njohur, si dhe të "parashikoni" ato që as nuk janë përmendur kurrë. Unë nuk kam qenë në gjendje ta vërtetoj rreptësisht këtë, por gjithashtu nuk di ende një kundërshembull. Në përgjithësi, kjo pyetje më kujtoi "Programin Erlangen" të Felix Klein. Në një kohë ai u përpoq të përfaqësonte të gjithë gjeometrinë si një degë të algjebrës (veçanërisht, teoria e grupit).
Tani tek pyetja kryesore - si po shkojnë gjërat me promovimin e Reiser4 në thelbin kryesor? A kishte ndonjë botim për arkitekturën e këtij skedari për të cilin folët në intervistën e fundit? Sa e rëndësishme është kjo pyetje nga këndvështrimi juaj?
Në përgjithësi kemi tre vjet që kërkojmë përfshirjen në degën kryesore. Komenti i fundit i Reiser në temën publike ku u bë kërkesa për tërheqje mbeti pa përgjigje. Pra, të gjitha pyetjet e mëtejshme nuk janë për ne. Unë personalisht nuk e kuptoj pse duhet të "bashkohemi" në një sistem operativ specifik. Në Linux, drita nuk konvergonte si një pykë. Pra, ekziston një depo e veçantë në të cilën do të ketë disa porte të degëve për OS të ndryshme. Kush ka nevojë për të, mund të klonojë portin përkatës dhe të bëjë çfarë të duash me të (në licencë, sigurisht). Epo, nëse dikush nuk ka nevojë për të, atëherë nuk është problemi im. Në këtë pikë, unë propozoj që çështja e "promovimit në kernelin kryesor të Linux" të konsiderohet si e zgjidhur.
Publikimet mbi arkitekturën FS janë relevante, por deri më tani kam gjetur kohë vetëm për rezultatet e mia të reja, të cilat i konsideroj si prioritet më të lartë. Një tjetër gjë është se unë jam matematikan, dhe në matematikë çdo botim është një përmbledhje e teoremave dhe provave të tyre. Publikimi i diçkaje atje pa prova është një shenjë e shijes së keqe. Nëse vërtetoj ose hedh poshtë plotësisht çdo deklaratë në lidhje me arkitekturën e FS, atëherë rezultati do të jetë grumbuj të tillë që do të jetë mjaft e vështirë të kalosh. Kush ka nevojë për të? Kjo është ndoshta arsyeja pse gjithçka vazhdon të mbetet në formën e saj të vjetër - kodi burimor dhe komentet për të.
Çfarë ka të re në Reiser4 gjatë viteve të fundit?
Stabiliteti i shumëpritur më në fund është materializuar. Një nga të fundit që u shfaq ishte një gabim që çoi në drejtoritë "të pafshirë". Vështirësia ishte se ai shfaqej vetëm në sfondin e përplasjeve të hash-it të emrave dhe me një vendndodhje të caktuar të regjistrimeve të drejtorisë në një nyje peme. Sidoqoftë, unë ende nuk mund ta rekomandoj Reiser4 për prodhim: për këtë ju duhet të bëni disa punë me ndërveprim aktiv me administratorët e sistemit të prodhimit.
Më në fund arritëm të zbatonim idenë tonë të kahershme - modele të ndryshme transaksionesh. Më parë, Reiser4 kishte vetëm një model Macdonald-Reiser të koduar. Kjo krijoi probleme të projektimit. Në veçanti, fotografitë e çastit nuk janë të mundshme në një model të tillë transaksioni - ato do të korruptohen nga një komponent atomik i quajtur "VENDOSUR SET". Reiser4 aktualisht mbështet tre modele transaksionesh. Në njërën prej tyre (Write-Anywhere), komponenti atomik OVERWRITE SET përfshin vetëm faqet e sistemit (imazhet e bitmap-ve të diskut, etj.), të cilat nuk mund të "fotografohen" (problemi i pulës dhe vezëve).
Kështu që fotot tashmë mund të realizohen në mënyrën më të mirë të mundshme. Në një model tjetër transaksional, të gjitha faqet e modifikuara shkojnë vetëm në SETIN E OVERWRITE (d.m.th., është në thelb ditar i pastër). Ky model është për ata që u ankuan për fragmentimin e shpejtë të ndarjeve Reiser4. Tani në këtë model ndarja juaj do të fragmentohet jo më shpejt se me ReiserFS (v3). Të tre modelet ekzistuese, me disa rezerva, garantojnë atomicitetin e operacioneve, por modelet me humbje të atomicitetit dhe duke ruajtur vetëm integritetin e seksionit mund të jenë gjithashtu të dobishëm. Modele të tilla mund të jenë të dobishme për të gjitha llojet e aplikacioneve (bazat e të dhënave, etj.), të cilat tashmë kanë marrë disa nga këto funksione. Është shumë e lehtë t'i shtosh këto modele në Reiser4, por nuk e bëra, sepse askush nuk më pyeti dhe unë personalisht nuk kam nevojë për të.
U shfaqën shumat e kontrollit të meta të dhënave dhe së fundmi i plotësova me pasqyra "ekonomike"" (material ende i paqëndrueshëm). Nëse shuma e kontrollit të ndonjë blloku dështon, Reiser4 lexon menjëherë bllokun përkatës nga pajisja replika. Vini re se ZFS dhe Btrfs nuk mund ta bëjnë këtë: dizajni nuk e lejon atë. Atje duhet të kryeni një proces të veçantë skanimi të sfondit të quajtur "scrub" dhe të prisni që ai të arrijë në bllokun problematik. Programuesit në mënyrë figurative i quajnë ngjarje të tilla "paterica".
Dhe së fundi, janë shfaqur vëllime heterogjene logjike, duke ofruar gjithçka që ZFS, Btrfs, shtresa e bllokut, si dhe kombinimet FS+LVM në parim nuk mund të ofrojnë - shkallëzimi paralel, alokuesi i adresave të diskut O(1), migrimi transparent i të dhënave midis nënvëllimeve. Ky i fundit ka gjithashtu një ndërfaqe përdoruesi. Tani mund t'i zhvendosni lehtësisht të dhënat më të nxehta në diskun me performancë më të lartë në volumin tuaj.
Përveç kësaj, është e mundur që urgjentisht të pastroni çdo faqe të ndotur në një disk të tillë, duke përshpejtuar ndjeshëm aplikacionet që shpesh thërrasin fsync(2). Unë vërej se funksionaliteti i shtresës së bllokut, i quajtur bcache, nuk ofron fare liri të tillë veprimi. Vëllimet e reja logjike bazohen në algoritmet e mia (ka patenta përkatëse). Softueri është tashmë mjaft i qëndrueshëm, është mjaft e mundur ta provoni, të matni performancën, etj. E vetmja shqetësim është se tani për tani ju duhet të përditësoni manualisht konfigurimin e volumit dhe ta ruani atë diku.
Deri më tani kam qenë në gjendje t'i zbatoj idetë e mia me 10 për qind, megjithatë, kam pasur sukses në atë që e konsideroja më të vështirë - lidhjen e vëllimeve logjike me një procedurë flash që kryen të gjitha veprimet e shtyra në reiser4. E gjithë kjo është ende në degën eksperimentale "format41".
A kalon Reiser4 xfstests?
Të paktën kështu ndodhi për mua kur isha duke përgatitur botimin e fundit.
A është e mundur në parim të bëhet Reiser4 një rrjet (grup) FS duke përdorur shtojca?
Është e mundur, madje edhe e nevojshme! Nëse krijoni një skedar rrjeti bazuar në një sistem skedari lokal të dizajnuar siç duhet, rezultati do të jetë shumë mbresëlënës! Në FS-të moderne të rrjetit, nuk jam i kënaqur me praninë e një niveli të ruajtjes së backend, i cili zbatohet duke përdorur çdo FS lokal. Ekzistenca e këtij niveli është krejtësisht e pajustifikuar. Rrjeti FS duhet të ndërveprojë drejtpërdrejt me shtresën e bllokut dhe të mos kërkojë nga FS lokale të krijojë ndonjë skedar tjetër shërbimi!
Në përgjithësi, ndarja e sistemeve të skedarëve në lokal dhe rrjet është nga e keqja. Ai lindi nga papërsosmëria e algoritmeve që u përdorën tridhjetë vjet më parë, dhe në vend të të cilave asgjë nuk është propozuar ende. Kjo është edhe arsyeja e shfaqjes së një mase komponentësh të panevojshëm softuerësh (shërbime të ndryshme, etj.). Në një mënyrë të mirë, duhet të ketë vetëm një FS në formën e një moduli kernel dhe një grup shërbimesh të përdoruesit të instaluar në secilën makinë - një nyje grupi. Ky FS është lokal dhe rrjet. Dhe asgjë më shumë!
Nëse asgjë nuk funksionon me Reiser4 në Linux, do të doja të ofroj një FS për FreeBSD (citim nga një intervistë e mëparshme: “...FreeBSD... ka rrënjë akademike... Dhe kjo do të thotë se me një shkallë të lartë probabiliteti ne do të gjejë një gjuhë të përbashkët me zhvilluesit”) ?
Pra, siç sapo zbuluam, gjithçka tashmë ka funksionuar në mënyrë të përsosur me Linux: ekziston një port i veçantë funksionues Reiser4 për të në formën e një dege master të depove tona. Nuk kam harruar FreeBSD! Oferta! Jam gati të punoj ngushtë me ata që e njohin mirë brendësinë e FreeBSD. Meqë ra fjala: ajo që më pëlqen shumë në komunitetin e tyre është se vendimet atje merren nga një këshill i përditësuar i ekspertëve të pavarur, që nuk ka të bëjë fare me mashtrimin e qeverisë ndaj një personi të përhershëm.
Si e vlerësoni komunitetin e përdoruesve të Linux sot? A është bërë më “pop”?
Duke pasur parasysh natyrën e punës sime, e kam mjaft të vështirë ta vlerësoj këtë. Kryesisht përdoruesit vijnë tek unë me raporte të gabimeve dhe kërkesa për të rregulluar seksionin. Përdoruesit si përdorues. Disa janë më të zgjuar, disa më pak. Të gjithë trajtohen njësoj. Epo, nëse përdoruesi i shpërfill udhëzimet e mia, atëherë më falni: urdhri i injorimit do të futet edhe nga ana ime.
A është e mundur të parashikohet zhvillimi i sistemeve të skedarëve për pesë deri në dhjetë vitet e ardhshme? Cilat mendoni se janë sfidat kryesore me të cilat mund të përballen zhvilluesit e FS?
Po, nuk është e vështirë të bësh një parashikim të tillë. Nuk ka pasur zhvillim të sistemeve të skedarëve në rrjedhën e sipërme për një kohë të gjatë. Vetëm pamja e tillë krijohet. Zhvilluesit e sistemeve të skedarëve lokalë hasën në probleme të lidhura me dizajnin e dobët. Këtu duhet bërë një paralajmërim. Unë nuk e konsideroj të ashtuquajturin "ruajtje", "lëpirje" dhe transferim të kodit si zhvillim dhe zhvillim. Dhe unë nuk e klasifikoj keqkuptimin e quajtur "Btrfs" si një zhvillim për arsyet që kam shpjeguar tashmë.
Çdo patch vetëm i përkeqëson problemet e tij. Epo. dhe ka gjithmonë lloje të ndryshme "ungjilltarësh" për të cilët "gjithçka funksionon". Në thelb, këta janë nxënës shkollash dhe studentë që anashkalojnë leksionet. Vetëm imagjinoni: funksionon për të, por profesori jo. Çfarë adrenaline është kjo! Nga këndvështrimi im, dëmi më i madh shkaktohet nga "mjeshtrit" që nxituan të "vidhosin" me entuziazëm tiparet e mrekullueshme të Btrfs në të gjitha llojet e shtresave si systemd, docker, etj. - kjo tashmë i ngjan metastazave.
Tani le të përpiqemi të bëjmë një parashikim për pesë deri në dhjetë vjet. Tashmë kam renditur shkurtimisht se çfarë do të bëjmë në Reiser4. Sfida kryesore për zhvilluesit lokalë të FS nga rrjedha e sipërme do të jetë (po, tashmë është bërë) pamundësia për të bërë një punë të mirë për një pagë. Pa asnjë ide në fushën e ruajtjes së të dhënave, ata do të vazhdojnë të përpiqen të rregullojnë këto VFS, XFS dhe ext4 fatkeq. Situata me VFS duket veçanërisht komike në këtë sfond, duke kujtuar modernizimin e furishëm të një restoranti në të cilin nuk ka kuzhinierë dhe nuk priten shefa.
Tani kodi VFS, pa asnjë kusht, bllokon disa faqe memorie në të njëjtën kohë dhe fton FS-në bazë që t'i operojë ato. Kjo u prezantua për të përmirësuar performancën e Ext4 në operacionet e fshirjes, por siç është e lehtë për t'u kuptuar, ky bllokim i njëkohshëm është plotësisht i papajtueshëm me modelet e avancuara të transaksioneve. Kjo do të thotë, nuk do të jeni në gjendje të shtoni thjesht mbështetje për disa sisteme skedarësh inteligjentë në kernel. Nuk e di se si është situata në fushat e tjera të Linux, por për sa i përket sistemeve të skedarëve, çdo zhvillim këtu nuk ka gjasa të jetë në përputhje me politikën e ndjekur nga Torvalds në praktikë (projektet akademike janë përjashtuar dhe mashtruesit që nuk e kanë idenë se çfarë një peme B, kredite të pafundme besimi janë lëshuar). Prandaj, u vendos një kurs për prishje të ngadaltë. Sigurisht, ata do të përpiqen me të gjitha forcat ta kalojnë atë si "zhvillim".
Më tej, "ruajtësit" e sistemeve të skedarëve, duke kuptuar se nuk do të fitoni shumë vetëm nga "magazinimi", do të provojnë dorën e tyre në një biznes më fitimprurës. Këto janë, si rregull, sisteme skedarësh të shpërndarë dhe virtualizim. Ndoshta ata do ta transferojnë ZFS-në në modë diku tjetër ku nuk ekziston ende. Por ajo, si të gjitha FS nga rrjedha e sipërme, i ngjan një peme të Vitit të Ri: nëse mund të varni disa gjëra të tjera të vogla sipër, atëherë nuk mund të futeni më thellë. E pranoj që është e mundur të ndërtohet një sistem serioz i ndërmarrjeve bazuar në ZFS, por meqenëse tani po diskutojmë të ardhmen, mund të them vetëm me trishtim se ZFS është e pashpresë në këtë drejtim: me pajisjet e tyre virtuale, djemtë kanë ndërprerë oksigjenin. për vete dhe brezat e ardhshëm për zhvillim të mëtejshëm. ZFS është një gjë e së kaluarës. Dhe ext4 dhe XFS nuk janë as pardje.
Vlen të përmendet veçmas për konceptin e bujshëm të "sistemit të skedarëve Linux të gjeneratës së ardhshme". Ky është një projekt tërësisht politik dhe marketingu i krijuar për mundësinë, si të thuash, për të “fiksuar të ardhmen e sistemeve të skedarëve” në Linux pas karaktereve specifike. Fakti është se Linux dikur ishte "vetëm për argëtim". Por tani ajo është kryesisht një makinë për të fituar para. Ato janë bërë në çdo gjë të mundshme. Për shembull, është shumë e vështirë të krijosh një produkt të mirë softuerësh, por "zhvilluesit" e zgjuar e kanë kuptuar prej kohësh se nuk ka nevojë të sforcohesh fare: mund të shesësh me sukses softuer joekzistent që u shpall dhe u promovua në të gjitha llojet e publikut. ngjarjet - gjëja kryesore është që rrëshqitjet e prezantimit duhet të përmbajnë më shumë "veçori".
Sistemet e skedarëve janë të përsosur për këtë, sepse mund të bëni pazare për dhjetë vjet për rezultatin. Epo, nëse dikush më vonë ankohet për mungesën e këtij rezultati, atëherë ai thjesht nuk kupton asgjë për sistemet e skedarëve! Kjo të kujton një piramidë financiare: në krye janë aventurierët që filluan këtë rrëmujë dhe ata pak që ishin "me fat": ata "tërhoqën dividentët", d.m.th. mori para për zhvillim, mori një punë të mirëpaguar si menaxher, "u shfaq" në konferenca, etj.
Më pas vijnë ata që janë "të pafat": ata do të numërojnë humbje, do të merren me pasojat e vendosjes së një produkti softuer të papërdorshëm në prodhim, "etj. Ka shumë më tepër prej tyre. Epo, në bazën e piramidës ka një masë të madhe zhvilluesish që "sharrojnë" kodin e padobishëm. Ata janë humbësit më të mëdhenj, sepse koha e humbur nuk kthehet më. Piramida të tilla janë jashtëzakonisht të dobishme për Torvalds dhe bashkëpunëtorët e tij. Dhe sa më shumë të jenë këto piramida, aq më mirë për ta. Për të ushqyer piramida të tilla, çdo gjë mund të merret në thelb. Sigurisht që në publik thonë të kundërtën. Por unë nuk gjykoj me fjalë, por me vepra.
Pra, "e ardhmja e sistemeve të skedarëve në Linux" është një tjetër softuer shumë i promovuar, por vështirë i përdorshëm. Pas Btrfs, me një probabilitet të lartë, vendin e një "e ardhmeje" të tillë do ta zërë Bcachefs, që është një përpjekje tjetër për të kaluar shtresën e bllokut Linux me një sistem skedari (një shembull i keq është ngjitës). Dhe ajo që është tipike: ka të njëjtat probleme si në Btrfs. Dyshova për këtë për një kohë të gjatë, dhe më pas disi nuk mund të rezistoja dhe shikova kodin - është e vërtetë!
Autorët e Bcachefs dhe Btrfs, kur krijuan FS-në e tyre, përdorën në mënyrë aktive burimet e njerëzve të tjerë, duke kuptuar pak rreth tyre. Situata të kujton shumë lojën e fëmijëve "telefon i prishur". Dhe përafërsisht mund ta imagjinoj se si do të përfshihet ky kod në kernel. Në fakt, askush nuk do t'i shohë "raketat" (të gjithë do t'i shkelin më vonë). Pas grindjeve të shumta rreth stilit të kodit, akuzave për shkelje joekzistente, etj., Do të bëhet një përfundim për "besnikërinë" e autorit, sa mirë "ndërvepron" ai me zhvilluesit e tjerë dhe sa me sukses mund të jetë e gjithë kjo. pastaj t'u shiten korporatave.
Rezultati përfundimtar nuk do t'i interesojë askujt. Njëzet vjet më parë ndoshta do të isha i interesuar, por tani pyetjet shtrohen ndryshe: a do të jetë e mundur të promovohet kjo në mënyrë që persona të caktuar të punësohen brenda dhjetë viteve të ardhshme. Dhe, mjerisht, nuk është zakon të pyesim veten për rezultatin përfundimtar.
Në përgjithësi, unë do të këshilloja fuqimisht të mos filloni të rishpikni sistemin tuaj të skedarëve nga e para. Sepse edhe investime të konsiderueshme financiare nuk do të mjaftojnë për të marrë diçka konkurruese në dhjetë vjet. Sigurisht, e kam fjalën për projekte serioze, dhe jo për ato që synohen të "shtyhen" në kernel. Pra, një mënyrë më efektive për t'u shprehur është t'i bashkoheni zhvillimeve reale, si ne. Kjo, natyrisht, nuk është e lehtë për t'u bërë - por ky është rasti me çdo projekt të nivelit të lartë.
Së pari, do t'ju duhet të kapërceni në mënyrë të pavarur problemin që do të ofroj. Pas së cilës, i bindur për seriozitetin e qëllimeve tuaja, do të filloj të ndihmoj. Tradicionalisht, ne përdorim vetëm zhvillimet tona. Përjashtimet janë algoritmet e kompresimit dhe disa funksione hash. Ne nuk i dërgojmë zhvilluesit të udhëtojnë në konferenca dhe më pas nuk ulemi dhe kombinojmë idetë e njerëzve të tjerë ("ndoshta çfarë do të ndodhë"), siç është zakon në shumicën e bizneseve fillestare.
Të gjitha algoritmet i zhvillojmë vetë. Aktualisht jam i interesuar në aspektet algjebrike dhe kombinuese të shkencës së ruajtjes së të dhënave. Në veçanti, fusha të fundme, asimptotika, prova e pabarazive. Ka edhe punë për programuesit e zakonshëm, por duhet t'ju paralajmëroj menjëherë: të gjitha sugjerimet për të "shikuar një FS tjetër dhe të bëni të njëjtën gjë" shpërfillen. Arna që synojnë integrimin më të afërt me Linux nëpërmjet VFS do të shkojnë gjithashtu atje.
Pra, ne nuk kemi një grabujë, por kemi një kuptim se ku duhet të lëvizim dhe kemi besim se ky drejtim është i duhuri. Ky kuptim nuk erdhi në formën e manës nga qielli. Më lejoni t'ju kujtoj se ne kemi 29 vjet përvojë zhvillimi pas nesh, dy sisteme skedarësh të shkruar nga e para. Dhe i njëjti numër i shërbimeve të rikuperimit të të dhënave. Dhe kjo është shumë!
Burimi: opennet.ru