Mahojiano ya pili na Eduard Shishkin, msanidi wa mfumo wa faili wa Reiser4, yamechapishwa.
Kuanza, tafadhali wakumbushe wasomaji unafanyia kazi wapi na nani.
Ninafanya kazi kama Mbunifu Mkuu wa Hifadhi katika Huawei Technologies, Kituo cha Utafiti cha Ujerumani. Katika idara ya uboreshaji ninashughulika na nyanja mbali mbali za uhifadhi wa data. Shughuli zangu hazihusiani na mfumo maalum wa uendeshaji.
Je, kwa sasa unajitolea kwa tawi kuu la kernel?
Mara chache sana, na ikiwa tu mwajiri wangu anahitaji. Mara ya mwisho ilikuwa kama miaka mitatu iliyopita, nilituma viraka ili kuongeza upitishaji kwa hifadhi iliyoshirikiwa kwa wapangishi kwa kutumia itifaki ya 9p (jina lingine la biashara hii ni VirtFS). Ujumbe mmoja muhimu lazima ufanywe hapa: ingawa nimekuwa nikifanya kazi na Linux kwa muda mrefu, sijawahi kuwa shabiki wake, ambayo ni, "ninapumua sawasawa," kama ilivyo kwa kila kitu kingine. Hasa, nikiona dosari, ninaweza kuionyesha mara moja. Na ili uweze kufuata mtu na kuwashawishi - hii haitatokea.
Nakumbuka mara ya mwisho, miaka kumi iliyopita, ulikuwa mkosoaji kabisa wa mtindo wa ukuzaji wa kernel. Kwa mtazamo wako (au labda wa ushirika), kuna lolote limebadilika, je, jumuiya imekuwa sikivu zaidi au la? Ikiwa sivyo, unadhani ni nani wa kulaumiwa?
Sijawahi kuona mabadiliko yoyote kwa bora. Shida kuu ya jamii ni uingizwaji wa sayansi na teknolojia za kisiasa, uhusiano wa kibinafsi, maoni ya wengi, populism, ushauri kutoka kwa "sauti za ndani," maelewano yaliyooza, kitu kingine chochote isipokuwa sayansi. Sayansi ya kompyuta, chochote mtu anaweza kusema, kwanza kabisa ni sayansi halisi. Na ikiwa mtu ataanza kutangaza thamani yake ya 2x2, tofauti na 4, chini ya bendera ya "Linux way", au chini ya bendera nyingine, basi hii haitawezekana kuleta chochote isipokuwa madhara.
Shida zote kimsingi zinatokana na uzembe na ukosefu wa elimu wa wale wanaofanya maamuzi. Ikiwa meneja hana uwezo, hana uwezo wa kufanya uamuzi wenye lengo na wa kutosha. Ikiwa yeye pia hana utamaduni, hawezi kupata mtaalamu mwenye uwezo ambaye atampa ushauri sahihi. Kwa uwezekano mkubwa, chaguo litaangukia kwa mlaghai ambaye anasema "mambo yanayoonekana kuwa sawa." Mazingira ya kifisadi daima hukua karibu na viongozi wapweke wasio na uwezo. Aidha, historia haijui isipokuwa katika suala hili, na jumuiya ndiyo uthibitisho wa wazi zaidi wa hili.
Je, unatathminije maendeleo katika maendeleo ya Btrfs? Je, FS hii iliondoa magonjwa ya utotoni? Je, unaiwekaje kwako - kama FS "ya nyumbani" au kwa matumizi ya shirika pia?
Sikuiondoa. Kila kitu nilichotaja miaka 11 iliyopita bado ni muhimu leo. Moja ya matatizo na Btrfs ambayo inafanya kuwa haifai kwa mahitaji makubwa ni tatizo la nafasi ya bure. Siongei hata juu ya ukweli kwamba mtumiaji anaulizwa kukimbia kwenye duka kwa diski mpya katika hali ambapo FS nyingine yoyote ingeonyesha nafasi nyingi za bure kwenye kizigeu. Kutokuwa na uwezo wa kukamilisha operesheni kwa kiasi cha mantiki kutokana na ukosefu wa nafasi ya bure pia sio jambo baya zaidi. Jambo baya zaidi ni kwamba mtumiaji asiye na upendeleo anaweza karibu kila wakati, kupita sehemu yoyote ya diski, kuwanyima kila mtu nafasi ya bure kwa muda mfupi.
Inaonekana kama hii (iliyojaribiwa kwa Linux kernel 5.12). Hati imezinduliwa kwenye mfumo mpya uliosanikishwa, ambao kwa kitanzi huunda faili zilizo na majina fulani kwenye saraka ya nyumbani, huwaandikia data kwa makosa fulani, na kisha kufuta faili hizi. Baada ya dakika ya kuendesha hati hii, hakuna kitu cha kawaida kinachotokea. Baada ya dakika tano, sehemu ya nafasi iliyochukuliwa kwenye kizigeu huongezeka kidogo. Baada ya saa mbili hadi tatu hufikia 50% (na thamani ya awali ya 15%). Na baada ya saa tano au sita za kazi, hati huanguka na kosa "hakuna nafasi ya bure kwenye kizigeu." Baada ya haya, hutaweza tena kuandika hata faili ya 4K kwenye kizigeu chako.
Hali ya kuvutia hutokea: uliishia kuandika chochote kwa kizigeu, na nafasi yote ya bure (karibu 85%) ilipotea mahali fulani. Uchambuzi wa sehemu iliyo chini ya shambulio kama hilo utafunua nodi nyingi za miti zilizo na kipengee kimoja tu (kitu kilicho na ufunguo), baiti kadhaa kwa ukubwa. Hiyo ni, yaliyomo ambayo hapo awali yalichukua 15% ya nafasi ya diski yaligeuka kuwa "smeared" sawasawa juu ya kizigeu nzima ili hakuna mahali pa kuandika faili mpya, kwa sababu ufunguo wake ni mkubwa kuliko zote zilizopo, na za bure. vitalu kwenye kizigeu vimeisha.
Kwa kuongezea, haya yote hufanyika tayari kwenye usanidi wa kimsingi wa Btrfs (bila muhtasari wowote, maandishi madogo, n.k.), na haijalishi unaamuaje kuhifadhi faili katika FS hiyo (kama "vipande" kwenye mti, au kama viwango. ya vizuizi visivyo na muundo) - matokeo ya mwisho yatakuwa sawa.
Hutaweza kuelekeza mifumo mingine ya juu ya faili kwa shambulio kama hilo (bila kujali wanakuambia nini). Nilielezea sababu ya tatizo muda mrefu uliopita: huu ni upotovu kamili wa dhana ya B-mti katika Btrfs, ambayo inafanya uwezekano wa kuharibika kwa hiari au kwa makusudi. Hasa, chini ya mizigo fulani, mfumo wako wa faili utaendelea "kuanguka" wakati wa uendeshaji peke yake, bila msaada wa nje. Ni wazi kwamba kila aina ya michakato ya mandharinyuma ya "kubonyeza" itaokoa siku tu kwenye kompyuta za mezani za kibinafsi.
Kwenye seva za pamoja, mshambuliaji ataweza "kuwatangulia" kila wakati. Msimamizi wa mfumo hataweza hata kuamua ni nani hasa alimdhulumu. Njia ya haraka ya kurekebisha tatizo hili katika Btrfs ni kurejesha muundo wa mti wa kawaida wa B, i.e. kuunda upya umbizo la diski na kuandika upya sehemu muhimu za msimbo wa Btrfs. Hii itachukua miaka 8-10, ikiwa ni pamoja na utatuzi, mradi watengenezaji walifuata kikamilifu makala asili kuhusu algoriti na miundo ya data husika, na hawakucheza mchezo wa "simu iliyovunjika", kama ilivyo kawaida (na kuhimizwa) katika "Linux. njiaβ.
Hapa tunahitaji pia kuongeza muda unaohitajika kwa watengenezaji kuelewa haya yote. Hapa ndipo inakuwa ngumu zaidi. Kwa vyovyote vile, miaka 10 haikutosha kwao kuelewa. Kweli, hadi wakati huo huwezi kutumaini muujiza. Haitatokea kwa namna ya chaguo la kufunga "ambalo wewe na mimi hatukujua," au kwa namna ya kiraka ambacho ni "suala la biashara tu" kuandaa. Kwa kila "kurekebisha" haraka kama hii nitawasilisha hali mpya ya kuzorota. B-miti ni moja ya mada ninayopenda, na lazima niseme kwamba miundo hii haivumilii uhuru na wao wenyewe!
Ninawezaje kuweka Btrfs kwa ajili yangu mwenyewe? Kama kitu ambacho hakiwezi kuitwa mfumo wa faili, achilia mbali kutumika. Kwa sababu, kwa ufafanuzi, FS ni mfumo mdogo wa OS unaowajibika kwa usimamizi mzuri wa rasilimali ya "nafasi ya diski", ambayo hatuoni katika kesi ya Btrfs. Kweli, fikiria kuwa ulikuja dukani kununua saa ili usichelewe kufanya kazi, na badala ya saa walikuuzia grill ya umeme na kipima saa kwa muda wa dakika 30. Kwa hivyo, hali ya Btrfs ni mbaya zaidi.
Kuangalia kupitia orodha za barua, mara nyingi mimi hukutana na taarifa kwamba kusimamia kwa ufanisi nafasi ya diski haifai tena kwa sababu ya bei nafuu ya anatoa. Huu ni upuuzi mtupu. Bila meneja bora wa nafasi ya diski, OS itakuwa hatarini na haiwezi kutumika. Bila kujali uwezo wa diski kwenye mashine yako.
Ningependa kuomba maoni juu ya kusitishwa kwa usaidizi wa Btrfs katika RHEL.
Hakuna kitu maalum cha kutoa maoni hapa, kila kitu kiko wazi sana. Pia walikuwa nayo kama "hakikisho la teknolojia". Kwa hiyo, sikupitia "hakikisho" hili sana. Usiruhusu lebo hii kuning'inia milele! Lakini hawawezi kuzindua bidhaa yenye kasoro ya muundo na usaidizi kamili. RHEL ni biashara, ambayo ni, uhusiano uliowekwa wa bidhaa na pesa. Red Hat haiwezi kudhulumu watumiaji kama wanavyofanya kwenye orodha ya wanaopokea barua pepe ya Btrfs. Hebu fikiria hali hiyo: mteja ambaye alilipa pesa zake ngumu kwa diski na pia wewe kwa usaidizi, anataka kuelewa mahali ambapo nafasi yake ya disk ilikwenda baada ya kuandika chochote. Utamjibu nini kwa hili?
Zaidi. Wateja wa Red Hat ni pamoja na benki kubwa zinazojulikana na kubadilishana. Hebu fikiria nini kingetokea ikiwa wangekabiliwa na mashambulizi ya DoS kulingana na mazingira magumu yaliyotajwa katika Btrfs. Unadhani nani anawajibika kwa hili? Kwa wale ambao wanakaribia kunyoosha kidole kwenye mstari wa leseni ya GPL, ambapo imeandikwa kwamba mwandishi hahusiki na chochote, mara moja nitasema: "Ficha mbali!" Kofia nyekundu itajibu, na kwa namna ambayo haitaonekana kutosha! Lakini najua kuwa Red Hat haikabiliwi na aina hii ya shida, kutokana na timu yao yenye nguvu ya wahandisi wa QA ambao nilipata fursa ya kufanya kazi nao kwa karibu wakati wangu.
Kwa nini baadhi ya makampuni yanaendelea kuunga mkono Btrfs katika bidhaa zao za biashara?
Tafadhali kumbuka kuwa kiambishi awali "biashara" katika jina la bidhaa haimaanishi sana. Biashara ni kipimo cha uwajibikaji kilichowekwa katika uhusiano wa kimkataba na mteja. Ninajua biashara moja tu kulingana na GNU/Linux - RHEL. Kila kitu kingine, kwa mtazamo wangu, kinawasilishwa tu kama biashara, lakini sio moja. Na hatimaye, ikiwa kuna mahitaji ya kitu, basi kutakuwa na usambazaji daima (kwa upande wetu, hii ndiyo "msaada" uliotajwa). Kuna mahitaji ya kila kitu kabisa, pamoja na. na programu isiyoweza kutumika. Jinsi mahitaji kama hayo yanaundwa na ni nani anayeichochea ni mada nyingine.
Kwa hivyo, nisingefikia hitimisho lolote baada ya Facebook kusemekana kuwa imetuma Btrfs kwenye seva zake. Zaidi ya hayo, ningependekeza kwa uangalifu kuweka anwani za seva hizo kwa siri kwa sababu zilizo hapo juu.
Kwa nini juhudi nyingi zimewekwa katika kusafisha nambari ya XFS hivi majuzi? Baada ya yote, awali hii ni mfumo wa faili wa tatu, na ext4 imekuwa imara kwa muda mrefu na ina mwendelezo kutoka kwa matoleo ya awali yaliyo sawa. Je, Red Hat ina maslahi gani katika XFS? Inaleta mantiki kukuza mifumo miwili ya faili ambayo ni sawa kwa kusudi - ext4 na XFS?
Sikumbuki ni nini kilichochea hii. Inawezekana kabisa kwamba mpango huo ulitoka kwa wateja wa Red Hat. Nakumbuka kwamba utafiti wa aina hii ulifanyika: kwenye baadhi ya mifumo ya faili kutoka kwenye mto, idadi kubwa ya vitu iliundwa kwenye anatoa za juu za kizazi kipya. Kulingana na matokeo, XFS iliishi bora kuliko ext4. Kwa hivyo walianza kuitangaza kama yenye kuahidi zaidi. Kwa vyovyote vile, nisingetafuta chochote cha kusisimua hapa.
Kwangu, ni kama wamebadilisha mkuro na sabuni. Hakuna maana katika kuendeleza ext4 na XFS. Wote kwa sambamba na yoyote kati yao ya kuchagua. Hakuna kitu kizuri kitakachokuja kutoka kwa hii. Ingawa, kwa asili kuna mara nyingi hali wakati kuna uwezekano mkubwa wa ukuaji, lakini hakuna nafasi ya kukua. Katika kesi hii, ukuaji mpya mbaya wa kushangaza huibuka, ambayo kila mtu anaashiria kidole ("Oh, angalia, hautaona nini katika maisha haya!").
Unafikiri suala la ukiukaji wa safu limetatuliwa (kwa maana mbaya) na ujio wa kazi za usimbaji fiche katika ext4, F2FS (bila kutaja RAID katika Btrfs)?
Kwa ujumla, kuanzishwa kwa ngazi yoyote na kufanya uamuzi kuhusu kutokiuka kwao kawaida ni suala la sera, na sijitokezi kutoa maoni juu ya chochote hapa. Vipengele vya lengo la ukiukaji wa safu havivutii mtu yeyote, lakini tunaweza kuzingatia baadhi yao kwa kutumia mfano wa ukiukaji "kutoka juu," yaani, utekelezaji katika FS ya utendaji ambayo tayari ipo kwenye safu ya kuzuia. "Ukiukaji" kama huo unahesabiwa haki isipokuwa nadra tu. Kwa kila kesi kama hiyo, lazima kwanza uthibitishe mambo mawili: kwamba inahitajika kweli, na kwamba muundo wa mfumo hautadhurika kwa kufanya hivyo.
Kwa mfano, kuakisi, ambayo kwa kawaida imekuwa shughuli kwa safu ya kuzuia, ina maana ya kutekeleza katika ngazi ya mfumo wa faili. Kwa sababu tofauti. Kwa mfano, uharibifu wa data "kimya" (bit rot) hutokea kwenye anatoa disk. Huu ndio wakati kifaa kinafanya kazi vizuri, lakini data ya kuzuia imeharibiwa bila kutarajia chini ya ushawishi wa gamma quantum ngumu iliyotolewa na quasar ya mbali, nk. Jambo baya zaidi ni ikiwa kizuizi hiki kinageuka kuwa kizuizi cha mfumo wa FS (superblock, bitmap block, node ya mti wa kuhifadhi, nk), kwa sababu hii hakika itasababisha hofu ya kernel.
Tafadhali kumbuka kuwa vioo vinavyotolewa na safu ya kuzuia (kinachojulikana RAID 1) haitakuokoa kutokana na tatizo hili. Kweli, mtu anapaswa kuangalia cheki na kusoma nakala ikiwa itashindwa? Kwa kuongeza, ni mantiki kuangazia sio kila kitu tu, lakini metadata tu. Baadhi ya data muhimu (kwa mfano, faili zinazotekelezeka za programu muhimu) zinaweza kuhifadhiwa kama metadata. Katika kesi hii, wanapokea dhamana sawa za usalama. Inaeleweka kukabidhi ulinzi wa data iliyobaki kwa mifumo mingine ndogo (labda hata programu za watumiaji) - tumetoa masharti yote muhimu kwa hili.
Vioo vile vya "kiuchumi" vina haki ya kuwepo, na vinaweza tu kupangwa kwa ufanisi katika ngazi ya mfumo wa faili. Vinginevyo, ukiukaji wa kuweka tabaka ni kukusanya mfumo mdogo wenye msimbo unaorudiwa kwa ajili ya manufaa fulani ya hadubini. Mfano wa kushangaza wa hii ni utekelezaji wa RAID-5 kwa kutumia FS. Suluhisho kama hizo (mwenyewe RAID / LVM kwenye mfumo wa faili) huua mwisho kwa maneno ya usanifu. Ikumbukwe pia hapa kwamba ukiukaji wa kuweka tabaka "huwekwa kwenye mkondo" na aina mbalimbali za walaghai wa uuzaji. Kwa kukosekana kwa maoni yoyote, utendakazi ambao umetekelezwa kwa muda mrefu katika viwango vya jirani huongezwa kwa mfumo mdogo, hii inawasilishwa kama kipengele kipya muhimu sana na inasukumwa kikamilifu.
Reiser4 alishutumiwa kwa kukiuka viwango "kutoka chini". Kulingana na ukweli kwamba mfumo wa faili sio monolithic, kama wengine wote, lakini wa kawaida, dhana isiyo na uthibitisho ilifanywa kwamba inafanya kile kiwango cha juu (VFS) kinapaswa kufanya.
Je, inawezekana kuzungumza juu ya kifo cha ReiserFS v3.6 na, kwa mfano, JFS? Hivi majuzi wamepokea karibu hakuna umakini katika msingi. Je, zimepitwa na wakati?
Hapa tunahitaji kufafanua nini maana ya kifo cha bidhaa ya programu. Kwa upande mmoja, hutumiwa kwa ufanisi (ndivyo walivyoumbwa, baada ya yote), ambayo inamaanisha wanaishi. Kwa upande mwingine, siwezi kuzungumza kwa JFS (sijui mengi), lakini ReiserFS (v3) ni vigumu sana kukabiliana na mwenendo mpya (iliyojaribiwa kwa mazoezi). Hii ina maana kwamba katika siku zijazo watengenezaji watazingatia sio, lakini kwa wale ambao ni rahisi kuzoea. Kutoka upande huu inageuka kuwa, ole, imekufa kwa maneno ya usanifu. Nisingeweza kuendesha dhana ya "kizamani kizamani" hata kidogo. Inatumika vizuri, kwa mfano, kwa WARDROBE, lakini si kwa bidhaa za programu. Kuna dhana ya uduni na ubora katika kitu. Ninaweza kusema kabisa kwamba ReserFS v3 sasa ni duni kwa Reiser4 katika kila kitu, lakini katika aina fulani za mzigo wa kazi ni bora kuliko FS zingine zote za juu.
Je, unajua kuhusu uundaji wa FS Tux3 na HAMMER/HAMMER2 (FS kwa DragonFly BSD)?
Ndiyo, tunajua. Katika Tux3 niliwahi kupendezwa na teknolojia ya vijipicha vyao (kinachojulikana kama "viashiria vya toleo"), lakini katika Reiser4 kuna uwezekano mkubwa wa kwenda njia tofauti. Nimekuwa nikifikiria juu ya kuunga mkono snapshots kwa muda mrefu na bado sijaamua jinsi ya kuzitekeleza kwa viwango rahisi vya Reiser4. Ukweli ni kwamba mbinu mpya ya kukabiliana na marejeleo ya "mvivu" iliyopendekezwa na Ohad Rodeh inafanya kazi tu kwa miti ya B. Hatuna yao. Kwa miundo ya data ambayo hutumiwa katika Reiesr4, kaunta "za uvivu" hazijafafanuliwa - ili kuzianzisha, ni muhimu kutatua matatizo fulani ya algorithmic, ambayo hakuna mtu amechukua bado.
Kulingana na HAMMER: Nilisoma makala kutoka kwa muundaji. Sivutiwi. Tena, B-miti. Muundo huu wa data umepitwa na wakati. Tuliiacha katika karne iliyopita.
Je, unatathminije mahitaji yanayokua ya nguzo za mtandao kama vile CephFS/GlusterFS/etc? Je, mahitaji haya yanamaanisha mabadiliko katika vipaumbele vya wasanidi programu kuelekea FS ya mtandao na umakini usiotosha kwa FS ya ndani?
Ndiyo, mabadiliko hayo katika vipaumbele yametokea. Uendelezaji wa mifumo ya faili ya ndani imedumaa. Ole, kufanya jambo muhimu kwa viwango vya kawaida sasa ni ngumu sana na sio kila mtu anayeweza kuifanya. Hakuna mtu anataka kuwekeza katika maendeleo yao. Hii ni sawa na kuuliza shirika la kibiashara kutenga pesa kwa utafiti wa hisabati - bila shauku yoyote watakuuliza jinsi unaweza kupata pesa kwenye nadharia mpya. Sasa FS ya ndani ni kitu kinachoonekana kichawi "nje ya boksi" na "kinapaswa kufanya kazi kila wakati," na ikiwa haifanyi kazi, husababisha manung'uniko yasiyoshughulikiwa kama: "Ndiyo, wanafikiria nini!"
Kwa hivyo kukosekana kwa umakini kwa FS ya ndani, ingawa bado kuna kazi nyingi katika eneo hilo. Na ndiyo, kila mtu amegeuka kwenye hifadhi iliyosambazwa, ambayo imejengwa kwa misingi ya mifumo ya faili ya ndani tayari. Ni mtindo sana sasa. Maneno "Data Kubwa" husababisha kukimbilia kwa adrenaline kwa wengi, kuihusisha na mikutano, warsha, mishahara mikubwa, nk.
Je, ni busara kiasi gani katika kanuni kutekeleza mfumo wa faili wa mtandao kwenye nafasi ya kernel badala ya nafasi ya mtumiaji?
Njia ya busara sana ambayo bado haijatekelezwa popote. Kwa ujumla, swali la ni katika nafasi gani mfumo wa faili wa mtandao unapaswa kutekelezwa ni "upanga wenye makali kuwili." Naam, tuangalie mfano. Mteja alirekodi data kwenye mashine ya mbali. Walianguka kwenye kashe ya ukurasa wake katika mfumo wa kurasa chafu. Hii ndio kazi ya mfumo wa faili wa mtandao wa "lango jembamba" kwenye nafasi ya kernel. Kisha mfumo wa uendeshaji utakuuliza mapema au baadaye uandike kurasa hizo kwenye diski ili kuzifungua. Kisha moduli ya FS ya mtandao wa IO ya kusambaza (kutuma) inakuja. Inaamua ni mashine gani ya seva (nodi ya seva) kurasa hizi zitaenda.
Kisha stack ya mtandao inachukua (na, kama tunavyojua, inatekelezwa katika nafasi ya kernel). Kisha, nodi ya seva hupokea pakiti hiyo iliyo na data au metadata na kuelekeza moduli ya uhifadhi wa mazingira ya nyuma (yaani, FS ya ndani inayofanya kazi katika nafasi ya kernel) kurekodi mambo haya yote. Kwa hiyo, tumepunguza swali ambapo moduli za "kutuma" na "kupokea" zinapaswa kufanya kazi. Iwapo mojawapo ya moduli hizo zitaendeshwa katika nafasi ya mtumiaji, hii itasababisha ubadilishaji wa muktadha (kwa sababu ya hitaji la kutumia huduma za kernel). Idadi ya swichi hizo inategemea maelezo ya utekelezaji.
Ikiwa kuna swichi nyingi kama hizo, basi njia ya uhifadhi (utendaji wa I/O) itapungua. Ikiwa hifadhi yako ya nyuma imeundwa na diski za polepole, basi hutaona kushuka kwa kiasi kikubwa. Lakini ikiwa una diski za haraka (SSD, NVRAM, nk), basi ubadilishaji wa muktadha tayari unakuwa "chupa" na, kwa kuokoa kwenye ubadilishaji wa muktadha, utendaji unaweza kuongezeka kwa kiasi kikubwa. Njia ya kawaida ya kuokoa pesa ni kuhamisha moduli kwenye nafasi ya kernel. Kwa mfano, tuligundua kuwa kuhamisha seva ya 9p kutoka QEMU hadi kernel kwenye mashine ya mwenyeji husababisha ongezeko la mara tatu la utendaji wa VirtFS.
Hii, bila shaka, sio FS ya mtandao, lakini inaonyesha kikamilifu kiini cha mambo. Upande mbaya wa uboreshaji huu ni masuala ya kubebeka. Kwa wengine, mwisho unaweza kuwa muhimu. Kwa mfano, GlusterFS haina moduli kwenye kernel hata kidogo. Shukrani kwa hili, sasa inafanya kazi kwenye majukwaa mengi, ikiwa ni pamoja na NetBSD.
Ni dhana gani FS za ndani zinaweza kukopa kutoka kwa zile za mtandao na kinyume chake?
Siku hizi, FS za mtandao, kama sheria, zina nyongeza juu ya FS za kawaida, kwa hivyo sielewi kabisa jinsi unaweza kukopa kitu kutoka kwa mwisho. Kweli, kwa kweli, hebu tuchunguze kampuni ya wafanyikazi 4, ambayo kila mtu hufanya jambo lake mwenyewe: moja inasambaza, nyingine inatuma, ya tatu inapokea, duka la nne. Na swali, kampuni inaweza kukopa nini kutoka kwa mfanyakazi wake ambaye huihifadhi, inaonekana kwa namna fulani si sahihi (tayari imekuwa na kile ambacho kingeweza kukopa kutoka kwake kwa muda mrefu).
Lakini FS za ndani zina mengi ya kujifunza kutoka kwa zile za mtandao. Kwanza, unapaswa kujifunza kutoka kwao jinsi ya kujumlisha kiasi cha kimantiki kwa kiwango cha juu. Sasa kinachojulikana Mifumo "ya hali ya juu" ya faili za ndani hujumlisha ujazo wa kimantiki kwa kutumia teknolojia ya "kifaa halisi" kilichokopwa kutoka LVM (ukiukaji ule ule wa tabaka unaoambukiza ambao ulitekelezwa kwa mara ya kwanza katika ZFS). Kwa maneno mengine, tafsiri ya anwani za kawaida (nambari za kuzuia) kuwa halisi na nyuma hutokea kwa kiwango cha chini (yaani, baada ya mfumo wa faili kutoa ombi la I / O).
Tafadhali kumbuka kuwa kuongeza na kuondoa vifaa kwa kiasi cha kimantiki (sio vioo) vilivyopangwa kwenye safu ya kuzuia husababisha matatizo ambayo wasambazaji wa "sifa" kama hizo huwa kimya. Ninazungumza juu ya kugawanyika kwenye vifaa halisi, ambavyo vinaweza kufikia maadili ya kutisha, wakati kwenye kifaa cha kawaida kila kitu kiko sawa. Hata hivyo, watu wachache wanavutiwa na vifaa pepe: kila mtu anavutiwa na kile kinachotokea kwenye vifaa vyako halisi. Lakini FS-kama FS (pamoja na FS yoyote kwa kushirikiana na LVM) hufanya kazi tu na vifaa vya diski halisi (tenga anwani za diski kutoka kati ya za bure, tenganisha vifaa hivi vya kawaida, nk). Na hawajui nini kinatokea kwenye vifaa halisi!
Sasa fikiria kuwa una mgawanyiko wa sifuri kwenye kifaa cha kawaida (ambayo ni, una kiwango kimoja tu cha kuishi hapo), unaongeza diski kwa kiasi chako cha kimantiki, na kisha uondoe diski nyingine isiyo ya kawaida kutoka kwa kiasi chako cha kimantiki na kisha kusawazisha. Na mara nyingi sana. Si vigumu kufikiria kuwa kwenye kifaa cha kawaida bado utakuwa na kiwango sawa cha kuishi, lakini kwenye vifaa halisi hutaona chochote kizuri.
Jambo baya zaidi ni kwamba huwezi hata kurekebisha hali hii! Kitu pekee unachoweza kufanya hapa ni kuuliza mfumo wa faili kuharibu kifaa cha kawaida. Lakini atakuambia kuwa kila kitu ni nzuri huko - kuna kiwango kimoja tu, kugawanyika ni sifuri, na haiwezi kuwa bora! Kwa hivyo, kiasi cha kimantiki kilichopangwa katika kiwango cha kuzuia sio lengo la kuongeza / kuondolewa mara kwa mara kwa vifaa. Kwa njia nzuri, unahitaji tu kukusanya kiasi cha mantiki kwenye ngazi ya kuzuia mara moja, kuwapa mfumo wa faili, na kisha usifanye chochote kingine nayo.
Kwa kuongeza, mchanganyiko wa mifumo ndogo ya FS + LVM hairuhusu kuzingatia asili tofauti ya anatoa ambayo kiasi cha mantiki kinakusanywa. Hakika, tuseme umekusanya kiasi cha kimantiki kutoka kwa HDD na vifaa vya hali dhabiti. Lakini basi ya kwanza itahitaji defragmentation, na mwisho si. Kwa mwisho, unahitaji kutoa maombi ya kutupa, lakini kwa wa kwanza, sio, nk. Walakini, katika mchanganyiko huu ni ngumu sana kuonyesha uteuzi kama huo.
Kumbuka kwamba baada ya kuunda LVM yako mwenyewe kwenye mfumo wa faili, hali haipatikani zaidi. Isitoshe, kwa kufanya hivi unakomesha kabisa matarajio ya kuiboresha siku zijazo. Hii ni mbaya sana. Aina tofauti za anatoa zinaweza kuishi kwenye mashine moja. Na ikiwa mfumo wa faili hautofautishi kati yao, basi nani atafanya?
Tatizo jingine liko katika kusubiri kwa kinachojulikana. Mifumo ya faili ya "Write-Popote" (hii pia inajumuisha Reiser4, ikiwa ulibainisha muundo unaofaa wa muamala wakati wa kupachika). Mifumo kama hiyo ya faili lazima itoe zana za utenganishaji ambazo hazijawahi kutokea katika uwezo wao. Na meneja wa kiwango cha chini haisaidii hapa, lakini anaingia tu. Ukweli ni kwamba na meneja kama huyo, FS yako itahifadhi ramani ya vitalu vya bure vya kifaa kimoja tu - cha kawaida. Ipasavyo, unaweza tu kutenganisha kifaa cha kawaida. Hii ina maana kwamba defragmenter yako itafanya kazi kwa muda mrefu, kwa muda mrefu kwenye nafasi moja kubwa ya anwani pepe.
Na ikiwa una watumiaji wengi wanaofanya mabadiliko ya nasibu, basi athari muhimu ya defragmenter kama hiyo itapunguzwa hadi sifuri. Mfumo wako utaanza kupungua polepole, na itabidi tu kukunja mikono yako mbele ya utambuzi wa kukatisha tamaa "muundo uliovunjika". Defragmenters kadhaa zinazoendesha kwenye nafasi moja ya anwani zitaingiliana tu. Ni jambo tofauti kabisa ikiwa utadumisha ramani yako mwenyewe ya vizuizi vya bure kwa kila kifaa halisi. Hii itasawazisha kwa ufanisi mchakato wa kugawanyika.
Lakini hii inaweza kufanyika tu ikiwa una meneja wa kiwango cha juu cha mantiki. Mifumo ya faili za mitaa na wasimamizi kama hao haikuwepo hapo awali (angalau, sijui juu yao). Mifumo ya faili za mtandao pekee (kwa mfano GlusterFS) ilikuwa na wasimamizi kama hao. Mfano mwingine muhimu sana ni matumizi ya kuangalia uadilifu wa kiasi (fsck). Ikiwa utahifadhi ramani yako ya kujitegemea ya vitalu vya bure kwa kila subvolume, basi utaratibu wa kuangalia kiasi cha mantiki unaweza kusawazishwa kwa ufanisi. Kwa maneno mengine, kiasi cha kimantiki kilicho na wasimamizi wa ngazi ya juu huwa bora zaidi.
Kwa kuongeza, ukiwa na wasimamizi wa kiwango cha chini hutaweza kupanga snapshots kamili. Ukiwa na mifumo ya faili ya LVM na ZFS, unaweza kupiga picha za ndani pekee, lakini sio picha za kimataifa. Vijipicha vya ndani hukuruhusu kurejesha utendakazi wa faili mara moja tu. Na hakuna mtu huko atakayerudisha nyuma shughuli na viwango vya kimantiki (kuongeza/kuondoa vifaa). Hebu tuangalie hili kwa mfano. Wakati fulani kwa wakati, unapokuwa na kiasi cha kimantiki cha vifaa viwili A na B vyenye faili 100, unachukua picha ya mfumo wa S na kisha kuunda faili nyingine mia.
Baada ya hapo, unaongeza kifaa C kwenye sauti yako, na hatimaye kurejesha mfumo wako ili kupiga picha S. Swali: Je, sauti yako ya kimantiki ina faili na vifaa ngapi baada ya kurejesha kwa S? Kutakuwa na faili 100, kama unavyoweza kukisia, lakini kutakuwa na vifaa 3 - hizi ni vifaa sawa A, B na C, ingawa wakati huo picha iliundwa kulikuwa na vifaa viwili tu kwenye mfumo (A na B). ) Uendeshaji wa kifaa cha kuongeza C haukurejeshwa nyuma, na ikiwa sasa utaondoa kifaa C kutoka kwa kompyuta, itaharibu data yako, kwa hivyo kabla ya kufuta utahitaji kwanza kufanya operesheni ya gharama kubwa ili kuondoa kifaa kutoka kwa kusawazisha kiasi cha kimantiki, ambacho itatawanya data yote kutoka kwa kifaa C hadi kifaa A na B. Lakini ikiwa FS yako ingeunga mkono vijipicha vya kimataifa, kusawazisha upya vile hakutahitajika, na baada ya kurejesha papo hapo kwa S, unaweza kuondoa kifaa C kutoka kwa kompyuta kwa usalama.
Kwa hiyo, snapshots za kimataifa ni nzuri kwa sababu zinakuwezesha kuepuka kuondolewa kwa gharama kubwa (kuongeza) kwa kifaa kutoka kwa kiasi cha mantiki (kwa kiasi cha mantiki) na kiasi kikubwa cha data (bila shaka, ikiwa unakumbuka "kupiga" mfumo wako. kwa wakati sahihi). Acha nikukumbushe kwamba kuunda snapshots na kurudisha mfumo wa faili kwao ni shughuli za papo hapo. Swali linaweza kutokea: inawezekanaje kurudisha operesheni mara moja kwa kiasi cha kimantiki ambacho kilikuchukua siku tatu? Lakini inawezekana! Isipokuwa kwamba mfumo wako wa faili umeundwa kwa usahihi. Nilikuja na wazo la "picha za 3D" kama hizo miaka mitatu iliyopita, na mwaka jana niliweka hati miliki ya mbinu hii.
Jambo linalofuata ambalo FS za ndani zinapaswa kujifunza kutoka kwa zile za mtandao ni kuhifadhi metadata kwenye vifaa tofauti kwa njia ile ile ambayo FS za mtandao huzihifadhi kwenye mashine tofauti (zinazojulikana kama seva za metadata). Kuna programu ambazo hufanya kazi kwa kutumia metadata, na programu hizi zinaweza kuharakishwa sana kwa kuweka metadata kwenye vifaa vya gharama kubwa vya uhifadhi wa utendaji wa juu. Ukiwa na mchanganyiko wa FS+LVM, hautaweza kuonyesha uteuzi kama huu: LVM haijui ni nini kwenye kizuizi ambacho ulipitisha kwake (data hapo au metadata).
Hutapata faida kubwa kutokana na kutekeleza LVM yako ya kiwango cha chini katika FS ikilinganishwa na mchanganyiko wa FS+LVM, lakini unachoweza kufanya vizuri sana ni kubandika FS ili baadaye iwe vigumu kufanya kazi na msimbo wake. ZFS na Btrfs, ambazo zilikimbia na vifaa vya kawaida, zote ni mifano wazi ya jinsi ukiukwaji wa safu unaua mfumo kwa maneno ya usanifu, kwa nini mimi ni haya yote? Kwa kuongeza, hakuna haja ya kusakinisha LVM yako ya kiwango cha chini kwenye mfumo wa faili. Badala yake, unahitaji kujumlisha vifaa katika viwango vya kimantiki kwa kiwango cha juu, kama mifumo mingine ya faili za mtandao hufanya na mashine tofauti (nodi za kuhifadhi). Kweli, wanafanya hivyo kwa kuchukiza kutokana na matumizi ya algorithms mbaya.
Mifano ya algoriti za kutisha kabisa ni mtafsiri wa DHT katika mfumo wa faili wa GlusterFS na kinachojulikana kama ramani ya CRUSH katika mfumo wa faili wa Ceph. Hakuna algoriti ambayo niliona iliniridhisha katika suala la urahisi na uboreshaji mzuri. Kwa hivyo ilinibidi kukumbuka algebra na kuvumbua kila kitu mwenyewe. Mnamo mwaka wa 2015, nilipokuwa nikijaribu vifurushi juu ya utendakazi wa heshi, nilikuja na kuweka hati miliki kitu ambacho kinanifaa. Sasa naweza kusema kwamba jaribio la kuweka haya yote katika vitendo lilifanikiwa. Sioni shida zozote za uboreshaji katika mbinu mpya.
Ndio, kila subvolume itahitaji muundo tofauti kama vile kizuizi kikubwa kwenye kumbukumbu. Je, hii inatisha sana? Kwa ujumla, sijui ni nani atakaye "chemsha bahari" na kuunda kiasi cha kimantiki cha mamia ya maelfu au vifaa zaidi kwenye mashine moja ya ndani. Ikiwa kuna mtu anaweza kunielezea hili, nitashukuru sana. Wakati huo huo, kwangu hii ni ujinga wa uuzaji.
Je, mabadiliko katika mfumo mdogo wa kifaa cha kuzuia kernel (kwa mfano, mwonekano wa blk-mq) yaliathiri vipi mahitaji ya utekelezaji wa FS?
Hawakuwa na athari yoyote. Sijui nini kitatokea kwenye safu ya kuzuia ambayo itafanya iwe muhimu kuunda FS mpya. Kiolesura cha mwingiliano wa mifumo hii midogo ni duni sana. Kutoka upande wa dereva, FS inapaswa kuathiriwa tu na kuonekana kwa aina mpya za anatoa, ambayo safu ya kuzuia itarekebishwa kwanza, na kisha FS (kwa reiser4 hii itamaanisha kuonekana kwa programu-jalizi mpya).
Je, kuibuka kwa aina mpya za media (kwa mfano, SMR, au kuenea kwa SSD) kunamaanisha changamoto mpya za muundo wa mfumo wa faili?
Ndiyo. Na hizi ni motisha za kawaida kwa maendeleo ya FS. Changamoto zinaweza kuwa tofauti na zisizotarajiwa kabisa. Kwa mfano, nimesikia juu ya anatoa ambapo kasi ya operesheni ya I/O inategemea sana saizi ya kipande cha data na urekebishaji wake. Katika Linux, ambapo saizi ya kizuizi cha FS haiwezi kuzidi saizi ya ukurasa, gari kama hilo halitaonyesha uwezo wake kamili kwa chaguo-msingi. Hata hivyo, ikiwa mfumo wako wa faili umeundwa kwa usahihi, basi kuna nafasi ya kupata mengi zaidi kutoka kwake.
Je, ni watu wangapi kwa sasa wanafanya kazi na msimbo wa Reiser4 kando na wewe?
Chini ya ningependa, lakini pia sipati uhaba mkubwa wa rasilimali. Nimeridhishwa zaidi na kasi ya maendeleo ya Reiser4. Sitaenda "kuendesha farasi" - hii sio eneo sahihi. Hapa, "ikiwa utaendesha gari kwa utulivu zaidi, utaendelea!" Mfumo wa kisasa wa faili ndio mfumo mdogo zaidi wa kernel, maamuzi yasiyo sahihi ya muundo ambayo yanaweza kutengua miaka inayofuata ya kazi ya mwanadamu.
Kwa kutoa watu wa kujitolea kutekeleza kitu, mimi huhakikishia kila wakati kwamba juhudi hakika zitasababisha matokeo sahihi, ambayo yanaweza kuwa katika mahitaji ya mahitaji makubwa. Kama unavyoelewa, hakuwezi kuwa na dhamana nyingi kama hizo mara moja. Wakati huo huo, siwezi kusimama "takwimu" ambazo zinakuza bila aibu "vipengele" vya programu isiyoweza kutumika, na kudanganya mamia ya watumiaji na watengenezaji, na wakati huo huo kukaa na kutabasamu kwenye mikutano ya kernel.
Je, kuna kampuni yoyote iliyoonyesha nia ya kusaidia maendeleo ya Reiser4?
Ndio, kulikuwa na mapendekezo kama haya, pamoja na. na kutoka kwa muuzaji mkuu. Lakini kwa hili nililazimika kuhamia nchi nyingine. Kwa bahati mbaya, sina umri wa miaka 30 tena, siwezi kujitenga na kuondoka kama hiyo kwenye filimbi ya kwanza.
Ni vipengele vipi ambavyo kwa sasa havipo kwenye Reiser4?
Hakuna kitendakazi cha "resize" kwa kiasi rahisi, sawa na ile inayopatikana katika ReiserFS(v3). Kwa kuongeza, utendakazi wa faili ulio na bendera ya DIRECT_IO hautaumiza. Ifuatayo, ningependa kuweza kugawanya kiasi katika "subvolumes za semantic", ambazo hazina saizi maalum, na ambazo zinaweza kuwekwa kama juzuu huru. Shida hizi ni nzuri kwa Kompyuta ambao wanataka kujaribu mkono wao kwenye "jambo halisi."
Na hatimaye, ningependa kuwa na kiasi cha mtandao cha mantiki na utekelezaji rahisi na utawala (algorithms za kisasa tayari kuruhusu hii). Lakini kile ambacho Reiser4 haitawahi kuwa nacho ni RAID-Z, vichaka, kashe za nafasi ya bure, vigeuzo vya 128-bit na upuuzi mwingine wa uuzaji ambao uliibuka dhidi ya hali ya nyuma ya uhaba wa mawazo kati ya watengenezaji wa mifumo fulani ya faili.
Je, kila kitu ambacho kinaweza kuhitajika kinaweza kutekelezwa na programu-jalizi?
Ikiwa tunazungumza tu kwa suala la miingiliano na programu-jalizi (moduli) zinazotekeleza, basi sio kila kitu. Lakini ikiwa pia utaanzisha uhusiano kwenye miingiliano hii, basi, kati ya mambo mengine, utakuwa na dhana ya polymorphisms ya juu, ambayo unaweza kupata nayo. Hebu fikiria kwamba umesimamisha mfumo wa wakati wa kukimbia unaoelekezwa na kitu, ukabadilisha thamani ya kielekezi cha maagizo ili kuelekeza kwenye programu-jalizi nyingine inayotumia kiolesura sawa cha X, na kisha kusimamisha mfumo ili uendelee kutekeleza.
Ikiwa mtumiaji wa mwisho haoni "badala" kama hiyo, basi tunasema kwamba mfumo una upolimishaji wa mpangilio wa sifuri katika kiolesura cha X (au mfumo ni tofauti katika kiolesura cha X, ambacho ni kitu kimoja). Ikiwa sasa huna tu seti ya miingiliano, lakini pia una mahusiano juu yao (grafu ya interface), basi unaweza kuanzisha polymorphisms ya maagizo ya juu, ambayo yatakuwa na sifa ya heterogeneity ya mfumo tayari katika "jirani" ya interface yoyote. Nilianzisha uainishaji kama huo muda mrefu uliopita, lakini, kwa bahati mbaya, haijawahi kutokea.
Kwa hiyo, kwa msaada wa programu-jalizi na polymorphisms ya juu zaidi, unaweza kuelezea kipengele chochote kinachojulikana, pamoja na "kutabiri" wale ambao hawajawahi hata kutajwa. Sijaweza kuthibitisha hili kwa uthabiti, lakini pia sijui mfano mwingine bado. Kwa ujumla, swali hili lilinikumbusha "Programu ya Erlangen" ya Felix Klein. Wakati mmoja alijaribu kuwakilisha jiometri yote kama tawi la algebra (haswa, nadharia ya kikundi).
Sasa kwa swali kuu - mambo yanaendeleaje na ukuzaji wa Reiser4 hadi msingi mkuu? Je, kulikuwa na machapisho yoyote kuhusu usanifu wa mfumo huu wa faili ambayo ulizungumzia katika mahojiano ya mwisho? Swali hili linafaa kwa kiasi gani kwa mtazamo wako?
Kwa ujumla, tumekuwa tukiomba kuingizwa katika tawi kuu kwa miaka mitatu. Maoni ya mwisho ya Reiser kwenye uzi wa umma ambapo ombi la kuvuta lilifanywa yalibaki bila kujibiwa. Kwa hivyo maswali yote zaidi sio kwetu. Mimi binafsi sielewi kwa nini tunahitaji "kuunganisha" kwenye mfumo maalum wa uendeshaji. Kwenye Linux, nuru haikuungana kama kabari. Kwa hivyo, kuna hazina tofauti ambayo kutakuwa na bandari kadhaa za tawi za OS tofauti. Yeyote anayehitaji anaweza kuiga bandari inayolingana na kufanya chochote unachotaka nayo (ndani ya leseni, bila shaka). Naam, ikiwa mtu haitaji, basi sio shida yangu. Katika hatua hii, ninapendekeza kuzingatia swali la "kukuza kwenye kernel kuu ya Linux" kama ilivyotatuliwa.
Machapisho juu ya usanifu wa FS yanafaa, lakini hadi sasa nimepata tu wakati wa matokeo yangu mapya, ambayo ninaona kuwa kipaumbele cha juu. Jambo lingine ni kwamba mimi ni mtaalamu wa hisabati, na katika hisabati uchapishaji wowote ni muhtasari wa nadharia na uthibitisho wao. Kuchapisha chochote hapo bila uthibitisho ni ishara ya ladha mbaya. Ikiwa nitathibitisha kabisa au kukanusha taarifa yoyote juu ya usanifu wa FS, basi matokeo yatakuwa piles ambayo itakuwa ngumu sana kupita. Nani anaihitaji? Labda hii ndiyo sababu kila kitu kinaendelea kubaki katika hali yake ya zamani - msimbo wa chanzo na maoni kwake.
Ni nini kipya katika Reiser4 katika miaka michache iliyopita?
Utulivu uliosubiriwa kwa muda mrefu hatimaye umeonekana. Moja ya mwisho kuonekana ilikuwa hitilafu iliyosababisha saraka "zisizoweza kufutwa". Ugumu ulikuwa kwamba ilionekana tu dhidi ya msingi wa migongano ya hashi ya jina na eneo fulani la rekodi za saraka kwenye nodi ya mti. Walakini, bado siwezi kupendekeza Reiser4 kwa uzalishaji: kwa hili unahitaji kufanya kazi fulani na mwingiliano hai na wasimamizi wa mfumo wa uzalishaji.
Hatimaye tuliweza kutekeleza wazo letu la muda mrefu - mifano tofauti ya shughuli. Hapo awali, Reiser4 iliendesha tu modeli moja ngumu ya Macdonald-Reiser. Hii iliunda matatizo ya kubuni. Hasa, snapshots haziwezekani katika mfano wa shughuli kama hiyo - zitaharibiwa na sehemu ya atomiki inayoitwa "OVERWRITE SET". Reiser4 kwa sasa inasaidia miundo mitatu ya muamala. Katika mojawapo yao (Andika-Popote), sehemu ya atomiki ya OVERWRITE SET inajumuisha kurasa za mfumo tu (picha za bitmaps za disk, nk), ambazo haziwezi "kupigwa picha" (tatizo la kuku na yai).
Kwa hivyo picha sasa zinaweza kufikiwa kwa njia bora zaidi. Katika muundo mwingine wa shughuli, kurasa zote zilizobadilishwa huenda tu kwa OVERWRITE SET (hiyo ni, kimsingi ni uandishi safi). Mfano huu ni wa wale ambao walilalamika juu ya mgawanyiko wa haraka wa sehemu za Reiser4. Sasa katika modeli hii kizigeu chako hakitagawanyika haraka kuliko na ReiserFS (v3). Mifano zote tatu zilizopo, pamoja na kutoridhishwa fulani, zinahakikisha atomicity ya shughuli, lakini mifano yenye kupoteza atomicity na kuhifadhi tu uadilifu wa sehemu pia inaweza kuwa muhimu. Vile mifano inaweza kuwa na manufaa kwa kila aina ya maombi (database, nk), ambayo tayari imechukua baadhi ya kazi hizi. Ni rahisi sana kuongeza mifano hii kwa Reiser4, lakini sikufanya hivyo, kwa sababu hakuna mtu aliniuliza, na mimi binafsi sihitaji.
Ukaguzi wa metadata ulionekana na hivi majuzi niliziongezea vioo vya "kiuchumi" (nyenzo bado haijatulia). Ikiwa hundi ya kizuizi chochote itashindwa, Reiser4 inasoma mara moja kizuizi kinacholingana kutoka kwa kifaa cha replica. Kumbuka kuwa ZFS na Btrfs haziwezi kufanya hivi: muundo hauruhusu. Huko lazima uendeshe mchakato maalum wa skanning ya mandharinyuma inayoitwa "scrub" na uisubiri ifike kwenye kizuizi chenye matatizo. Watayarishaji wa programu kwa njia ya mfano huita matukio kama hayo "magongo."
Na mwishowe, idadi kubwa ya kimantiki imeonekana, ikitoa kila kitu ambacho ZFS, Btrfs, safu ya kuzuia, na mchanganyiko wa FS + LVM kimsingi hauwezi kutoa - kuongeza kiwango sawa, O (1) kigawa anwani ya diski, uhamiaji wa data wazi kati ya subvolumes. Mwisho pia una kiolesura cha mtumiaji. Sasa unaweza kuhamisha data motomoto kwa urahisi hadi kwenye hifadhi yenye utendaji wa juu zaidi kwenye sauti yako.
Kwa kuongeza, inawezekana kufuta kwa haraka kurasa zozote chafu kwenye gari kama hilo, na hivyo kuharakisha kwa kiasi kikubwa programu ambazo mara nyingi huita fsync(2). Ninaona kuwa utendakazi wa safu ya kuzuia, inayoitwa bcache, haitoi uhuru kama huo wa hatua hata kidogo. Kiasi kipya cha kimantiki kinatokana na algoriti zangu (kuna hataza zinazolingana). Programu tayari ni imara kabisa, inawezekana kabisa kujaribu, kupima utendaji, nk. Usumbufu pekee ni kwamba kwa sasa unahitaji kusasisha usanidi wa sauti kwa mikono na kuihifadhi mahali pengine.
Kufikia sasa nimeweza kutekeleza maoni yangu kwa asilimia 10, Walakini, nimefaulu katika kile nilichoona kuwa kitu kigumu zaidi - kuunganisha idadi ya kimantiki na utaratibu wa flash ambao hufanya vitendo vyote vilivyoahirishwa katika reiser4. Hii yote bado iko kwenye tawi la majaribio la "format41".
Je, Reiser4 inapita xfstests?
Angalau ilinifanyia nilipokuwa nikitayarisha toleo la mwisho.
Inawezekana kimsingi kufanya Reiser4 mtandao (nguzo) FS kwa kutumia programu-jalizi?
Inawezekana, na hata ni lazima! Ikiwa utaunda faili ya mtandao kulingana na mfumo wa faili wa ndani ulioundwa vizuri, matokeo yatakuwa ya kushangaza sana! Katika FS za kisasa za mtandao, sijaridhika na uwepo wa kiwango cha uhifadhi wa nyuma, ambacho kinatekelezwa kwa kutumia FS yoyote ya ndani. Uwepo wa kiwango hiki haufai kabisa. FS ya mtandao lazima iingiliane moja kwa moja na safu ya kuzuia, na sio kuuliza FS ya ndani kuunda faili zingine za huduma!
Kwa ujumla, kugawanya mifumo ya faili ndani ya ndani na mtandao ni kutoka kwa yule mwovu. Ilitoka kutokana na kutokamilika kwa algorithms ambayo ilitumiwa miaka thelathini iliyopita, na mahali ambapo hakuna kitu kilichopendekezwa. Hii pia ndiyo sababu ya kuonekana kwa wingi wa vipengele vya programu zisizohitajika (huduma mbalimbali, nk). Kwa njia nzuri, inapaswa kuwa na FS moja tu kwa namna ya moduli ya kernel na seti ya huduma za mtumiaji zilizowekwa kwenye kila mashine - node ya nguzo. FS hii ni ya ndani na mtandao. Na hakuna zaidi!
Ikiwa hakuna kitu kinachofanya kazi na Reiser4 kwenye Linux, ningependa kutoa FS kwa FreeBSD (nukuu kutoka kwa mahojiano ya awali: "...FreeBSD... ina mizizi ya kitaaluma ... Na hii ina maana kwamba kwa kiwango cha juu cha uwezekano sisi utapata lugha ya kawaida na watengenezaji")?
Kwa hivyo, kama tulivyogundua, kila kitu tayari kimefanya kazi kikamilifu na Linux: kuna bandari tofauti ya Reiser4 inayofanya kazi kwa njia ya tawi kuu la hazina yetu. Sijasahau kuhusu FreeBSD! Toa! Niko tayari kufanya kazi kwa karibu na wale wanaojua mambo ya ndani ya FreeBSD vizuri. Kwa njia: ninachopenda sana kuhusu jumuiya yao ni kwamba maamuzi huko yanafanywa na baraza la wataalam wa kujitegemea, ambalo halihusiani na udanganyifu wa serikali wa mtu mmoja wa kudumu.
Je, unakadiria vipi jumuiya ya watumiaji wa Linux leo? Imekuwa "pop" zaidi?
Kwa kuzingatia asili ya kazi yangu, ni ngumu sana kwangu kutathmini hii. Watumiaji wengi huja kwangu na ripoti za hitilafu na maombi ya kurekebisha sehemu hiyo. Watumiaji kama watumiaji. Baadhi ni wajuzi zaidi, wengine chini. Kila mtu anatendewa sawa. Kweli, ikiwa mtumiaji atapuuza maagizo yangu, basi nisamehe: agizo la kupuuza litaingizwa kwa upande wangu pia.
Je, inawezekana kutabiri maendeleo ya mifumo ya faili kwa miaka mitano hadi kumi ijayo? Je, unafikiri ni changamoto gani kuu ambazo watengenezaji wa FS wanaweza kukabiliana nazo?
Ndiyo, si vigumu kufanya utabiri huo. Hakujakuwa na maendeleo ya mifumo ya faili kwenye sehemu ya juu kwa muda mrefu. Kuonekana tu kwa vile kunaundwa. Watengenezaji wa mifumo ya faili za ndani walikutana na matatizo yanayohusiana na muundo mbaya. Tahadhari inapaswa kufanywa hapa. Sichukulii kile kinachoitwa "hifadhi", "kulamba" na uwekaji wa msimbo kuwa maendeleo na maendeleo. Na siainishi kutoelewana kunakoitwa "Btrfs" kama maendeleo kwa sababu ambazo tayari nimeelezea.
Kila kiraka hufanya shida zake kuwa mbaya zaidi. Vizuri. na daima kuna aina mbalimbali za βwainjilistiβ ambao βkila kitu hufanya kaziβ kwao. Kimsingi, hawa ni watoto wa shule na wanafunzi wanaoruka mihadhara. Hebu fikiria: inafanya kazi kwa ajili yake, lakini profesa hana. Hii ni kasi ya adrenaline iliyoje! Kwa mtazamo wangu, madhara makubwa zaidi yanasababishwa na "mafundi" ambao walikimbilia "kuruka" kwa shauku vipengele vya ajabu vya Btrfs kwenye kila aina ya safu kama vile systemd, docker, nk. - hii tayari inafanana na metastases.
Hebu sasa tujaribu kufanya utabiri wa miaka mitano hadi kumi. Tayari nimeorodhesha kwa ufupi kile tutafanya katika Reiser4. Changamoto kuu kwa watengenezaji wa FS wa ndani kutoka juu itakuwa (ndiyo, tayari imekuwa) kutoweza kufanya kazi nzuri kwa mshahara. Bila mawazo yoyote katika uga wa uhifadhi wa data, wataendelea kujaribu kuweka viraka hivi VFS, XFS na ext4. Hali ya VFS inaonekana ya kuchekesha sana dhidi ya historia hii, ikikumbusha hali ya kisasa ya mgahawa ambayo hakuna mpishi, na hakuna mpishi anayetarajiwa.
Sasa msimbo wa VFS, bila masharti yoyote, hufunga kurasa kadhaa za kumbukumbu kwa wakati mmoja na kualika FS ya msingi kuzifanyia kazi. Hii ilianzishwa ili kuboresha utendaji wa Ext4 kwenye shughuli za kufuta, lakini kama ilivyo rahisi kuelewa, kufunga kwa wakati mmoja hakuoani kabisa na miundo ya hali ya juu ya ununuzi. Hiyo ni, hautaweza kuongeza tu usaidizi kwa mfumo fulani wa faili mahiri kwenye kernel. Sijui hali ikoje katika maeneo mengine ya Linux, lakini kuhusu mifumo ya faili inavyohusika, maendeleo yoyote hapa hayana uwezekano wa kuendana na sera inayofuatwa na Torvalds kivitendo (miradi ya kitaaluma inafukuzwa, na walaghai ambao sijui ni mti gani wa B , mikopo isiyoisha ya uaminifu hutolewa). Kwa hivyo, kozi iliwekwa kwa kuoza polepole. Bila shaka, watajaribu kwa nguvu zao zote kuipitisha kama βmaendeleo.β
Zaidi ya hayo, "walinzi" wa mifumo ya faili, wakitambua kwamba huwezi kupata mengi kutoka kwa "hifadhi" pekee, watajaribu mkono wao katika biashara yenye faida zaidi. Hizi ni, kama sheria, mifumo ya faili iliyosambazwa na uboreshaji. Labda wataweka ZFS ya mtindo mahali pengine ambapo haipo bado. Lakini, kama FS yote kutoka juu ya mto, inafanana na mti wa Mwaka Mpya: ikiwa unaweza kunyongwa vitu vingine vidogo juu, basi huwezi kupata zaidi. Ninakubali kwamba inawezekana kujenga mfumo mzito wa biashara kulingana na ZFS, lakini kwa kuwa sasa tunajadili siku zijazo, naweza kusema kwa huzuni tu kwamba ZFS haina tumaini katika suala hili: na vifaa vyao vya kawaida, watu hao wamekata oksijeni. wao wenyewe na vizazi vijavyo kwa maendeleo zaidi. ZFS ni jambo la zamani. Na ext4 na XFS sio siku moja kabla ya jana.
Inafaa kutaja kando juu ya dhana ya kupendeza ya "mfumo wa faili wa Linux wa kizazi kijacho". Huu ni mradi wa kisiasa na uuzaji ulioundwa kwa fursa, kwa kusema, "kuweka mifumo ya baadaye ya faili" katika Linux nyuma ya herufi maalum. Ukweli ni kwamba Linux ilikuwa "ya kujifurahisha tu". Lakini sasa kimsingi ni mashine ya kutengeneza pesa. Zinatengenezwa kwa kila linalowezekana. Kwa mfano, ni ngumu sana kuunda bidhaa nzuri ya programu, lakini "watengenezaji" wenye akili wamegundua kwa muda mrefu kuwa hakuna haja ya kusumbua hata kidogo: unaweza kuuza kwa mafanikio programu ambayo haipo ambayo ilitangazwa na kukuzwa kwa kila aina ya umma. matukio - jambo kuu ni kwamba slaidi za uwasilishaji zinapaswa kuwa na "vipengele" zaidi.
Mifumo ya faili ni kamili kwa hili, kwa sababu unaweza kufanya biashara kwa usalama kwa miaka kumi juu ya matokeo. Kweli, ikiwa mtu baadaye analalamika juu ya ukosefu wa matokeo haya, basi haelewi chochote kuhusu mifumo ya faili! Hii ni kukumbusha piramidi ya kifedha: juu ni wasafiri ambao walianza fujo hili, na wale wachache ambao walikuwa "bahati": "waliondoa gawio," i.e. alipokea pesa za maendeleo, akapata kazi iliyolipwa vizuri kama wasimamizi, "alionekana" kwenye mikutano, nk.
Ifuatayo inakuja wale ambao "hawana bahati": watahesabu hasara, kukabiliana na matokeo ya kupeleka bidhaa ya programu isiyoweza kutumika katika uzalishaji, "nk. Kuna wengi zaidi wao. Kweli, chini ya piramidi kuna wingi mkubwa wa watengenezaji "wanaoona" msimbo usio na maana. Hao ndio wapotezaji wakubwa, kwa sababu wakati uliopotea hauwezi kurejeshwa. Piramidi kama hizo zina faida kubwa kwa Torvalds na washirika wake. Na zaidi ya piramidi hizi, ni bora kwao. Ili kulisha piramidi kama hizo, chochote kinaweza kuchukuliwa ndani ya msingi. Bila shaka, kwa umma wanasema kinyume. Lakini sihukumu kwa maneno bali kwa matendo.
Kwa hivyo, "mustakabali wa mifumo ya faili katika Linux" bado ni programu nyingine iliyokuzwa sana, lakini isiyoweza kutumika. Baada ya Btrfs, kwa uwezekano mkubwa, mahali pa "baadaye" hiyo itachukuliwa na Bcachefs, ambayo ni jaribio jingine la kuvuka safu ya kuzuia Linux na mfumo wa faili (mfano mbaya unaambukiza). Na ni nini kawaida: kuna shida sawa na katika Btrfs. Nilishuku hii kwa muda mrefu, halafu kwa njia fulani sikuweza kupinga na kuangalia nambari - ni kweli!
Waandishi wa Bcachefs na Btrfs, wakati wa kuunda FS zao, walitumia kikamilifu vyanzo vya watu wengine, wakielewa kidogo juu yao. Hali hiyo inakumbusha sana mchezo wa watoto "simu iliyovunjika." Na ninaweza kufikiria jinsi nambari hii itajumuishwa kwenye kernel. Kwa kweli, hakuna mtu atakayeona "rakes" (kila mtu atazikanyaga baadaye). Baada ya mabishano mengi juu ya mtindo wa nambari, mashtaka ya ukiukaji ambao haupo, nk, hitimisho litafanywa juu ya "uaminifu" wa mwandishi, jinsi "anavyoingiliana" na watengenezaji wengine, na jinsi haya yote yanaweza kufanikiwa. kisha kuuzwa kwa mashirika.
Matokeo ya mwisho hayatavutia mtu yeyote. Miaka ishirini iliyopita, labda, ningekuwa na nia, lakini sasa maswali yanafanywa tofauti: itawezekana kukuza hili ili watu fulani wataajiriwa ndani ya miaka kumi ijayo. Na, ole, sio kawaida kujiuliza juu ya matokeo ya mwisho.
Kwa ujumla, ningeshauri sana dhidi ya kuanza kuunda tena mfumo wako wa faili kutoka mwanzo. Kwa sababu hata uwekezaji mkubwa wa kifedha hautatosha kupata kitu cha ushindani katika miaka kumi. Kwa kweli, ninazungumza juu ya miradi mikubwa, na sio juu ya yale ambayo yanalenga "kusukuma" kwenye kernel. Kwa hivyo, njia bora zaidi ya kujieleza ni kujiunga na maendeleo halisi, kama sisi. Hii, bila shaka, si rahisi kufanya - lakini hii ni kesi na mradi wowote wa ngazi ya juu.
Kwanza, utahitaji kujitegemea kuondokana na tatizo ambalo nitatoa. Baada ya hapo, nikiwa na hakika ya uzito wa nia yako, nitaanza kusaidia. Kijadi, tunatumia tu maendeleo yetu wenyewe. Isipokuwa ni kanuni za ukandamizaji na baadhi ya vipengele vya heshi. Hatutumi wasanidi programu kusafiri kwa mikutano, na kisha hatuketi na kuchanganya mawazo ya watu wengine ("labda nini kitatokea"), kama ilivyo kawaida katika kuanzisha nyingi.
Tunatengeneza algoriti zote sisi wenyewe. Kwa sasa ninavutiwa na vipengele vya aljebra na muunganisho wa sayansi ya kuhifadhi data. Hasa, mashamba ya mwisho, asymptotics, uthibitisho wa kutofautiana. Pia kuna kazi kwa waandaaji wa programu za kawaida, lakini lazima nikuonye mara moja: mapendekezo yote ya "kuangalia FS nyingine na kufanya hivyo" yanapuuzwa. Viraka vinavyolenga kuunganishwa kwa karibu na Linux kupitia VFS pia vitaenda huko.
Kwa hiyo, hatuna tafuta, lakini tuna ufahamu wa wapi tunahitaji kuhamia, na tuna imani kwamba mwelekeo huu ni sahihi. Ufahamu huu haukuja kwa namna ya mana kutoka mbinguni. Acha nikukumbushe kwamba tuna miaka 29 ya uzoefu wa maendeleo nyuma yetu, mifumo miwili ya faili iliyoandikwa kutoka mwanzo. Na idadi sawa ya huduma za kurejesha data. Na hii ni mengi!
Chanzo: opennet.ru