Mahojiano ya pili na Eduard Shishkin, msanidi wa mfumo wa faili wa Reiser4, yamechapishwa.
Kwa kuanzia, tafadhali wakumbushe wasomaji unafanya kazi wapi na nani.
Ninafanya kazi kama Mbunifu Mkuu wa Hifadhi katika Huawei Technologies, Kituo cha Utafiti cha Ujerumani. Katika idara ya uboreshaji, ninafanya kazi kwenye nyanja mbali mbali za uhifadhi wa data. Kazi yangu haijazingatia mfumo maalum wa uendeshaji.
Je, unajitolea kwa tawi kuu la kernel sasa?
Mara chache sana, na ikiwa tu mwajiri wangu anahitaji. Mara ya mwisho nilipowasilisha viraka ilikuwa kama miaka mitatu iliyopita, ili kuongeza upitishaji wa uhifadhi ulioshirikiwa kwa wapangishi kwa kutumia itifaki ya 9p (pia inajulikana kama VirtFS). Ujumbe mmoja muhimu hapa: ingawa nimekuwa nikifanya kazi na Linux kwa muda mrefu, sijawahi kuwa shabiki wa Linux. Siipendi sana, kwani mimi ni wa kila kitu kingine. Hasa, nikiona dosari, nitaionyesha mara moja. Sitalazimika kumfuata mtu na kumshawishi baadaye.
Nakumbuka mara ya mwisho, miaka kumi iliyopita, ulikuwa mkosoaji wa mtindo wa msingi wa maendeleo. Je, kuna kitu kimebadilika kutoka kwa mtazamo wako (au pengine wa shirika)? Je, jamii imekuwa sikivu zaidi? Ikiwa sivyo, unadhani ni nani wa kulaumiwa?
Sijaona mabadiliko yoyote chanya. Tatizo kuu la jamii ni ubadilishaji wa sayansi na teknolojia za kisiasa, mahusiano ya kibinafsi, maoni ya wengi, umaarufu, ushauri kutoka kwa "sauti za ndani," maelewano yaliyooza - chochote isipokuwa sayansi. Sayansi ya kompyuta, haijalishi unaiangaliaje, kwanza kabisa, ni sayansi halisi. Na ikiwa mtu anaanza kutangaza maana ya 2x2 ambayo inatofautiana na 4, chini ya bendera ya "Linux "njia", au chini ya nyingine yoyote, basi hakuna uwezekano wa kuleta chochote isipokuwa madhara."
Shida zote zinatokana hasa na uzembe na ukosefu wa elimu wa wale wanaofanya maamuzi. Ikiwa kiongozi hana uwezo, hana uwezo wa kufanya maamuzi yenye malengo na ya kutosha. Ikiwa pia hawana utamaduni, hawawezi kupata mtaalamu mwenye uwezo ambaye atawapa ushauri sahihi. Wana uwezekano wa kuchagua mtu mlaghai ambaye "anaonekana kusema jambo sahihi." Viongozi wapweke wasio na uwezo daima hujenga mduara wa ufisadi kuwazunguka. Historia haijui isipokuwa kwa hili, na jumuiya ni mfano wa wazi zaidi wa hili.
Je, unakadiriaje maendeleo ya Btrfs? Je, mfumo huu wa faili umeondoa matatizo yake ya kuota meno? Je, unaiwekaje—kama mfumo wa faili wa nyumbani au kwa matumizi ya shirika pia?
Sikuiondoa. Kila kitu nilichotaja miaka 11 iliyopita bado ni muhimu leo. Mojawapo ya matatizo ya Btrfs, na kuifanya kuwa haifai kwa matumizi makubwa, ni suala la nafasi ya bure. Bila kutaja kwamba mtumiaji analazimika kukimbia kwenye duka kwa kiendeshi kipya katika hali ambapo mfumo mwingine wowote wa faili ungeonyesha nafasi nyingi za bure kwenye kizigeu. Kukosa kukamilisha operesheni kwa sauti ya kimantiki kwa sababu ya nafasi isiyo na nafasi ya kutosha sio jambo baya zaidi. Jambo baya zaidi ni kwamba mtumiaji asiye na upendeleo anaweza karibu kila mara kumaliza haraka nafasi ya bure ya kila mtu, kupitisha upendeleo wowote wa diski.
Inaonekana kama hii (ilijaribiwa kwa kernel Linux 5.12). Kwenye mfumo mpya uliosakinishwa, hati huendeshwa ambayo huunda faili zenye majina maalum kwenye saraka ya nyumbani kwa mzunguko, huziandika data katika sehemu maalum za kuhesabu, na kisha hufuta faili hizi. Baada ya dakika moja ya kuendesha hati hii, hakuna jambo lisilo la kawaida linalotokea. Baada ya dakika tano, nafasi inayokaliwa kwenye kizigeu huongezeka kidogo. Baada ya saa mbili hadi tatu, hufikia 50% (kutoka thamani ya awali ya 15%). Na baada ya saa tano hadi sita, hati huanguka na hitilafu "hakuna nafasi ya bure kwenye kizigeu." Baada ya haya, huwezi tena kuandika hata faili ya 4K kwenye kizigeu chako.
Hali ya kupendeza inatokea: haukuandika chochote kwa kizigeu, na nafasi yote ya bure (takriban 85%) imetoweka. Uchambuzi wa kizigeu kinachokabiliwa na shambulio kama hilo utafichua nodi nyingi za miti zilizo na kitu kimoja tu (kitu kilicho na ufunguo), baiti chache kwa ukubwa. Kwa maneno mengine, yaliyomo ambayo hapo awali yalichukua 15% ya nafasi ya diski imekuwa "smeared" sawasawa katika sehemu nzima, kwa hivyo hakuna nafasi ya kuandika faili mpya, kwani ufunguo wake ni mkubwa kuliko zote zilizopo, na kizigeu kimeisha kwa vizuizi vya bure.
Kwa kuongezea, haya yote hufanyika tayari kwenye usanidi wa msingi wa Btrfs (bila picha ndogo, subvolumes, n.k.), na haijalishi jinsi unavyoamua kuhifadhi faili katika FS hiyo (kama "vipande" kwenye mti, au kama viwango vya vizuizi visivyo na muundo) - matokeo ya mwisho yatakuwa sawa.
Hutaweza kuelekeza mifumo mingine ya juu ya faili kwenye shambulio kama hilo (bila kujali mtu yeyote atakuambia nini). Tayari nimeelezea sababu ya tatizo: Btrfs inapotosha kabisa dhana ya mti B, na kuifanya iweze kuathiriwa na kuzorota kwa hiari au kimakusudi. Hasa, chini ya mzigo fulani wa kazi, mfumo wako wa faili utaendelea "kuanguka" peke yake wakati wa operesheni, bila msaada wowote wa nje. Ni wazi, kila aina ya michakato ya mandharinyuma ya "kushinikiza" itaokoa siku kwenye kompyuta za mezani pekee.
Kuhusu zile za pamoja seva Mshambuliaji ataweza "kuwatangulia" kila wakati. Msimamizi wa mfumo hataweza hata kubaini ni nani hasa aliyekuwa akimtumia vibaya. Njia ya haraka zaidi ya kurekebisha tatizo hili katika Btrfs ni kurejesha muundo wa mti wa kawaida wa B, yaani, kubuni upya umbizo la diski na kuandika upya sehemu muhimu ya msimbo wa Btrfs. Hii itachukua miaka 8-10, ikiwa ni pamoja na utatuzi wa matatizo, mradi tu wasanidi programu walifuata kwa makini karatasi asilia kwenye algoriti na miundo husika ya data, na hawakucheza "simu iliyovunjika", kama ilivyo kawaida (na kuhimizwa) katikaLinux njia".
Lazima pia uongeze wakati inachukua kwa watengenezaji kubaini haya yote. Hapo ndipo inakuwa ngumu zaidi. Kwa vyovyote vile, miaka 10 haikutosha kwao kufahamu. Hadi wakati huo, usitegemee muujiza. Haitakuja kwa namna ya chaguo la kuweka "hatukujua" au kiraka ambacho ni "kipande cha keki." Kwa kila "marekebisho" kama haya ya haraka, nitawasilisha hali mpya ya kuzorota. B-miti ni moja ya mada ninayopenda, na lazima niseme, miundo hii haivumilii uhuru!
Je, ninawekaje Btrfs? Kama kitu ambacho hakiwezi kuitwa mfumo wa faili, achilia mbali kutumika. Kwa ufafanuzi, mfumo wa faili ni mfumo mdogo wa OS unaohusika na usimamizi bora wa nafasi ya diski, ambayo sivyo ilivyo kwa Btrfs. Hebu wazia ukienda dukani kununua saa ili usichelewe kazini, na badala yake wanakuuzia grill ya umeme yenye kipima muda kinachodumu kwa dakika 30. Kweli, kwa Btrfs, hali ni mbaya zaidi.
Wakati nikivinjari orodha za barua, mara nyingi mimi hukutana na madai kwamba usimamizi mzuri wa nafasi ya diski haufai tena kwa sababu anatoa ni nafuu sana. Huu ni upuuzi mtupu. Bila meneja mzuri wa nafasi ya diski, OS itakuwa hatarini na haiwezi kutumika, bila kujali uwezo wa anatoa kwenye mashine yako.
Ningependa kuuliza maoni juu ya mwisho wa msaada kwa Btrfs katika RHEL.
Hakuna mengi ya kutoa maoni hapa; kila kitu kiko wazi. Ilikuwa "hakikisho lao la teknolojia." Naam, haikuifanya kupita ile "hakikisho." Hawawezi kuweka lebo hiyo milele! Na hawawezi kuzindua bidhaa yenye kasoro, iliyosanifiwa na usaidizi kamili. RHEL ni biashara, kumaanisha kuwa imefafanua mahusiano ya bidhaa na pesa. Red Hat haiwezi kudhulumu watumiaji kama wanavyofanya kwenye orodha ya wanaopokea barua pepe ya Btrfs. Hebu fikiria hili: mteja ambaye alilipa pesa alizochuma kwa bidii kwa diski na pia kwa usaidizi wako anataka kujua nafasi yake ya diski ilienda wapi baada ya kuwa hawajaandika chochote. Ungewaambia nini?
Inayofuata. Wateja wa Red Hat ni pamoja na benki kubwa zinazojulikana na kubadilishana. Hebu fikiria nini kingetokea ikiwa wangeshambuliwa na DoS kulingana na athari iliyotajwa hapo juu katika Btrfs. Unadhani nani angewajibishwa? Kwa wale ambao wanakaribia kutaja mstari katika leseni ya GPL ambayo inasema mwandishi hahusiki, nasema mara moja: "Ficha!" Red Hat itajibu, na kwa njia ambayo itakuwa mshtuko kabisa! Lakini najua kwamba Red Hat haiko katika hatari ya matatizo hayo, 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?
Kumbuka kwamba kiambishi awali "biashara" katika jina la bidhaa haimaanishi mengi. Biashara ni kipimo cha uwajibikaji kilichowekwa katika uhusiano wa kimkataba na mteja. Ninajua biashara moja tu inayotegemea GNU.Linux — huyo ni RHEL. Kila kitu kingine, kwa maoni yangu, kinajifanya kama biashara, lakini sivyo. Na mwishowe, ikiwa kuna mahitaji ya kitu, kutakuwa na usambazaji kila wakati (kwa upande wetu, huo ndio "msaada" uliotajwa hapo juu). Mahitaji yanaweza kuwa ya kila kitu, ikiwa ni pamoja na programu isiyotumika. Jinsi mahitaji haya yanavyoundwa, na ni nani anayeyachochea, ni mada nyingine kabisa.
Kwa hivyo, singekurupuka kufikia hitimisho lolote baada ya uvumi wa Facebook kusambaza Btrfs kwenye seva zake. Zaidi ya hayo, anwani za wale seva Ningependekeza kuiweka kwa uangalifu kwa sababu zilizotajwa hapo juu.
Kwa nini juhudi nyingi zimewekwa katika kung'arisha nambari ya XFS hivi majuzi? Baada ya yote, awali ilikuwa mfumo wa faili wa tatu, na ext4 kwa muda mrefu imekuwa imara na ina urithi wa matoleo ya awali, sawa sawa. Ni nini maslahi ya Red Hat katika XFS? Inaleta mantiki kukuza mifumo miwili ya faili kwa madhumuni sawa-ext4 na XFS?
Sikumbuki motisha nyuma yake. Inawezekana kabisa kwamba mpango huo ulitoka kwa wateja wa Red Hat. Nakumbuka kulikuwa na masomo kama haya: kwa kutumia mifumo ya faili ya juu, idadi kubwa ya vitu iliundwa kwenye anatoa za mwisho za kizazi kipya. Matokeo yalionyesha kuwa XFS ilifanya vizuri zaidi kuliko ext4. Kwa hivyo walianza kuitangaza kama yenye kuahidi zaidi. Kwa vyovyote vile, nisingetarajia chochote cha kustaajabisha hapa.
Kwa maoni yangu, wamebadilisha kitu kimoja hadi kingine. Hakuna maana katika kukuza ext4 na XFS. Ama kwa sambamba au kwa chaguo lolote. Hakuna kitu kizuri kitakachokuja kutoka kwake. Ingawa, kwa asili, mara nyingi kuna hali ambapo kuna uwezekano mkubwa wa ukuaji, lakini hakuna uwezo wa kupanua. Katika kesi hii, kila aina ya ukuaji wa ajabu, mbaya mpya hutokea, ambayo kila mtu anaashiria ("Oh, angalia mambo yote ambayo unaweza kuona katika maisha haya!").
Je, unafikiri suala la ukiukaji wa safu linatatuliwa (kwa maana mbaya) kwa ujio wa vipengele vya usimbaji fiche katika ext4, F2FS (bila kutaja RAID katika Btrfs)?
Kwa ujumla, kutambulisha tabaka zozote na kuamua kuzikiuka kwa kawaida ni suala la sera, na sitatoa maoni kulihusu. Malengo ya vipengele vya ukiukaji wa safu havivutiwi sana na mtu yeyote, lakini tunaweza kuchunguza baadhi yao kwa kutumia mfano wa ukiukaji wa juu-chini-haswa, utendakazi ambao tayari upo kwenye safu ya kuzuia katika mfumo wa faili. "Ukiukwaji" kama huo unahesabiwa haki kwa ubaguzi wa nadra. Kwa kila kesi kama hiyo, lazima kwanza uthibitishe mambo mawili: kwamba ni muhimu sana, na kwamba haitadhuru muundo wa mfumo.
Kwa mfano, kioo, kilichohifadhiwa kwa jadi kwa safu ya kuzuia, ina maana ya kutekeleza katika ngazi ya mfumo wa faili. Kuna sababu mbalimbali za hili. Kwa mfano, anatoa disk huathirika na uharibifu wa data kimya (bit rot). Hii hutokea wakati kifaa kinafanya kazi vizuri, lakini data katika block imeharibiwa bila kutarajia na mionzi ya gamma ngumu iliyotolewa na quasar ya mbali, nk Hali mbaya zaidi ni wakati kizuizi hiki ni kuzuia mfumo wa faili (superblock, bitmap block, node ya mti wa kuhifadhi, nk), kwani hii itasababisha hofu ya kernel.
Kumbuka kuwa vioo vinavyotolewa na safu ya kuzuia (kinachojulikana kama RAID 1) havitasuluhisha shida hii. Baada ya yote, mtu lazima ahakikishe ukaguzi na kusoma nakala ikiwa itashindwa. Kwa kuongezea, inaeleweka kuangazia metadata tu, sio kila kitu. Baadhi ya data muhimu (kwa mfano, faili zinazotekelezeka za programu muhimu) zinaweza kuhifadhiwa kama metadata. Katika kesi hii, wanapokea dhamana sawa za usalama. Inaleta maana kukabidhi ulinzi wa data nyingine kwa mifumo mingine midogo (labda hata programu za mtumiaji)—tumetoa masharti yote muhimu kwa hili.
Vioo vile "vya gharama nafuu" vinawezekana kabisa, na vinaweza tu kutekelezwa kwa ufanisi katika ngazi ya mfumo wa faili. Ukiukaji wa tabaka, hata hivyo, ni kuunganisha tu mfumo mdogo na msimbo unaorudiwa kwa ajili ya manufaa fulani ya hadubini. Mfano mkuu ni utekelezaji wa RAID-5 ndani ya mfumo wa faili. Suluhisho kama hizo (asili RAID/LVM ndani ya mfumo wa faili) huharibu mfumo wa faili kwa usanifu. Inafaa pia kuzingatia kwamba ukiukaji wa kuweka tabaka "umetolewa kwa wingi" na walaghai mbalimbali wa uuzaji. Kwa kukosa mawazo yoyote asilia, utendakazi ambao tayari umetekelezwa katika viwango vya karibu huongezwa kwa mifumo ndogo, inayowasilishwa kama kipengele kipya, muhimu sana, na kukuzwa kikamilifu.
Reiser4 alishutumiwa kwa kukiuka tabaka "chini." Ikizingatiwa kuwa mfumo wa faili sio monolithic kama wengine wote, lakini wa kawaida, dhana isiyo na msingi ilifanywa kwamba hufanya kile safu hapo juu (VFS) inapaswa kufanya.
Je, ni salama kusema kwamba ReiserFS v3.6 na, kwa mfano, JFS wamekufa? Wamekuwa wakipokea umakini mdogo kwenye kernel hivi majuzi. Je, zimepitwa na wakati?
Hapa tunahitaji kufafanua maana ya bidhaa ya programu kuwa imekufa. Kwa upande mmoja, zinatumiwa kwa mafanikio (ndivyo walivyoumbwa, baada ya yote), kwa hiyo wako hai. Kwa upande mwingine, siwezi kuzungumza kwa JFS (sijui mengi), lakini ReiserFS (v3) ni vigumu sana kukabiliana na mwenendo mpya (kama inavyothibitishwa katika mazoezi). Hii ina maana kwamba watengenezaji watazingatia masuluhisho yaliyo rahisi kuzoea badala ya JFS katika siku zijazo. Kwa maana hii, ni, kwa bahati mbaya, imekufa kwa usanifu. Nisingetumia neno "kizamani" hata kidogo. Inatumika vizuri, sema, WARDROBE, lakini si kwa programu. Kuna dhana ya kuwa duni na bora katika kitu. Ninaweza kusema kwa uhakika kabisa kwamba ReiserFS v3 kwa sasa ni duni kwa Reiser4 kwa kila njia, lakini kwa aina fulani za mzigo wa kazi, inashinda mifumo mingine yote ya juu ya faili.
Je, unafahamu maendeleo ya Tux3 na HAMMER/HAMMER2 (FS kwa DragonFly BSD) FS?
Ndiyo, najua. Katika Tux3, niliwahi kupendezwa na teknolojia yao ya muhtasari (kinachojulikana kama "viashiria vilivyobadilishwa"), lakini katika Reiser4 kuna uwezekano mkubwa kuchukua njia tofauti. Nimekuwa nikifikiria juu ya usaidizi wa snapshot kwa muda sasa na bado sijaamua jinsi ya kuitekeleza kwa viwango rahisi vya Reiser4. Jambo ni kwamba, mbinu mpya ya kukabiliana na marejeleo ya "mvivu" iliyopendekezwa na Ohad Rodeh inafanya kazi tu kwa miti ya B. Hatuna yoyote. Kaunta za uvivu hazijafafanuliwa kwa miundo ya data inayotumika katika Reiser4—kuitekeleza kunahitaji kutatua matatizo fulani ya algorithmic, ambayo bado hakuna mtu aliyeyashughulikia.
Kuhusu HAMMER: Nilisoma makala ya muundaji. Haikunivutia. Tena, B-miti. Muundo huu wa data umepitwa na wakati. Tuliiacha nyuma katika karne iliyopita.
Unatathminije hitaji linalokua la mifumo ya faili za nguzo za mtandao kama CephFS/GlusterFS/etc.? Je, mahitaji haya yanaonyesha mabadiliko katika vipaumbele vya wasanidi programu kuelekea mifumo ya faili za mtandao na ukosefu wa umakini kwa mifumo ya faili za ndani?
Ndiyo, mabadiliko hayo katika vipaumbele yametokea. Uendelezaji wa mifumo ya faili ya ndani imedumaa. Kwa bahati mbaya, kufanya chochote muhimu kwa viwango vya ndani sasa ni ngumu sana na mbali na kila mtu anaweza kushughulikia. Hakuna anayetaka kuwekeza kwenye maendeleo yao. Ni takriban sawa na kuuliza huluki ya kibiashara kutenga pesa kwa ajili ya utafiti wa hisabati—watakuuliza, bila ethnos yoyote, jinsi wanavyoweza kupata pesa kutoka kwa nadharia mpya. Sasa, mfumo wa faili wa ndani ni kitu ambacho kinaonekana kichawi "nje ya boksi" na "kinapaswa kufanya kazi kila wakati," na ikiwa haifanyi kazi, husababisha manung'uniko yasiyojibiwa kwenye mistari ya, "Wanawaza nani?"
Kwa hivyo ukosefu wa umakini kwa mifumo ya faili ya ndani, ingawa bado kuna kazi kubwa katika eneo hili. Na ndiyo, kila mtu amegeukia mifumo ya hifadhi iliyosambazwa iliyojengwa juu ya mifumo iliyopo ya faili za ndani. Ni hasira zote sasa hivi. Maneno "Data Kubwa" huchochea kasi ya adrenaline kwa wengi, ikihusisha na mikutano, warsha, mishahara mikubwa, na kadhalika.
Njia hiyo ni ya busara kwa kanuni, ambayo mfumo wa faili wa mtandao unatekelezwa kwenye nafasi ya kernel, na sio katika nafasi ya mtumiaji?
Njia ya busara sana, ambayo haijatekelezwa popote bado. Kwa ujumla, swali la wapi kutekeleza mfumo wa faili wa mtandao ni upanga wenye ncha mbili. Hebu tuangalie mfano. Mteja anaandika data kwa mashine ya mbali. Inaishia kwenye kashe ya ukurasa wake kama kurasa chafu. Hii ndio kazi ya "lango nyembamba" la mfumo wa faili wa mtandao kwenye nafasi ya kernel. Hivi karibuni au baadaye, mfumo wa uendeshaji utaomba kwamba kurasa hizo ziandikwe kwenye diski ili kuzifungua. Kisha moduli ya usambazaji wa IO ya mfumo wa faili ya mtandao inaingia. Inabainisha ni mashine gani ya seva (nodi ya seva) kurasa hizi zitaishia.
Kisha stack ya mtandao (ambayo, kama tunavyojua, inatekelezwa katika nafasi ya kernel) inachukua nafasi. Ifuatayo, nodi ya seva inapokea pakiti iliyo na data au metadata na inaelekeza moduli ya uhifadhi wa nyuma (yaani, mfumo wa faili wa ndani unaoendesha nafasi ya kernel) ili kuandika yote. Kwa hivyo, tumepunguza swali hadi moduli za "kutuma" na "kupokea" zinapaswa kufanya kazi. Iwapo moduli mojawapo itafanya kazi katika nafasi ya mtumiaji, hii bila shaka itasababisha swichi za muktadha (kutokana na hitaji la kutumia huduma za kernel). Idadi ya swichi hizo inategemea maelezo ya utekelezaji.
Ikiwa kuna swichi nyingi kama hizo, uhifadhi (utendaji wa I/O) utashuka. Ikiwa hifadhi yako ya nyuma inajumuisha diski za polepole, hutaona kushuka kwa kiasi kikubwa. Lakini ikiwa una diski za haraka (SSD, NVRAM, nk), swichi za muktadha huwa kizuizi, na kwa kuokoa kwenye swichi za muktadha, utendaji unaweza kuongezeka kwa kiasi kikubwa. Njia ya kawaida ya kufanikisha hili ni kusonga moduli hadi nafasi ya kernel. Kwa mfano, tuligundua kuwa kuhamisha seva ya 9p kutoka QEMU hadi kernel ya mwenyeji kulisababisha ongezeko la mara tatu la utendaji wa VirtFS.
Huu sio mfumo wa faili wa mtandao, kwa kweli, lakini hupata uhakika. Upande mbaya wa uboreshaji huu ni masuala ya kubebeka. Kwa wengine, mwisho unaweza kuwa muhimu. Kwa mfano, GlusterFS haina moduli za kernel hata kidogo. Shukrani kwa hili, sasa inaendesha kwenye majukwaa mengi, ikiwa ni pamoja na NetBSD.
Ni dhana gani FS za ndani zinaweza kukopa kutoka kwa FS za mtandao na kinyume chake?
Siku hizi, mifumo ya faili za mtandao kawaida hujengwa juu ya mifumo ya faili ya kawaida, kwa hivyo sielewi kabisa jinsi mtu yeyote anaweza kukopa chochote kutoka kwa mfumo wa pili. Hakika, fikiria kampuni yenye wafanyakazi wanne, kila mmoja akifanya jambo lake mwenyewe: moja inasambaza, mtu anatuma, mmoja anapokea, na duka moja. Na swali la nini kampuni inaweza kukopa kutoka kwa mfanyakazi ambaye huhifadhi inaonekana kuwa haifai (tayari wamekuwa na kile wangeweza kukopa kutoka kwake kwa muda mrefu).
Mifumo ya faili za mitaa, hata hivyo, ina mengi ya kujifunza kutoka kwa mifumo ya faili za mtandao. Kwanza, wanapaswa kujifunza jinsi ya kujumlisha kiasi cha kimantiki kwa kiwango cha juu. Hivi sasa, kinachojulikana kama mifumo ya faili ya ndani "ya hali ya juu" inajumlisha kiasi cha kimantiki kwa kutumia teknolojia ya "kifaa halisi" kilichokopwa kutoka LVM (ukiukaji sawa wa kuweka tabaka ambao ulitekelezwa mara ya kwanza katika ZFS). Kwa maneno mengine, anwani za kawaida (nambari za kuzuia) zinatafsiriwa kwenye anwani halisi na kurudi kwa kiwango cha chini (yaani, baada ya mfumo wa faili kutoa ombi la I / O).
Kumbuka kuwa kuongeza na kuondoa vifaa kwa kiasi cha kimantiki (sio vioo) vilivyosanidiwa kwenye safu ya kuzuia husababisha matatizo ambayo wachuuzi wa vipengele hivyo hunyamaza kimya. Ninazungumza juu ya kugawanyika kwenye vifaa halisi, ambavyo vinaweza kufikia viwango vya kutisha, wakati kila kitu kiko sawa kwenye kifaa cha kawaida. Hata hivyo, vifaa pepe havivutiwi sana na mtu yeyote: kila mtu anavutiwa na kinachoendelea kwenye vifaa vyako halisi. Lakini mifumo ya faili kama ya ZFS (pamoja na mifumo yoyote ya faili kwa kushirikiana na LVM) inafanya kazi tu na vifaa vya diski halisi (kugawa anwani za diski kutoka kwa nafasi inayopatikana ya diski, kugawanya vifaa hivi vya kawaida, nk). Na hawajui nini kinatokea kwenye vifaa halisi!
Sasa fikiria kuwa kifaa chako cha mtandaoni kina mgawanyiko wa sifuri (ikimaanisha kuwa una kiwango kimoja tu kikubwa hapo), unaongeza diski kwa kiasi chako cha kimantiki, na kisha uondoe diski nyingine isiyo ya kawaida kutoka kwa kiasi cha kimantiki, ikifuatiwa na kusawazisha tena. Na kadhalika, mara nyingi. Ni rahisi kujua kuwa bado utakuwa na kiwango hicho kimoja kwenye kifaa pepe, lakini hutaona chochote kizuri kwenye vifaa halisi.
Sehemu mbaya zaidi ni kwamba, huwezi hata kurekebisha hali hii! Kitu pekee unachoweza kufanya ni kuuliza mfumo wa faili kuharibu kifaa cha kawaida. Lakini itakuambia kila kitu ni sawa-kuna kiwango kimoja tu, kugawanyika ni sifuri, na hiyo ni nzuri kama inavyopata! Kwa hivyo, kiasi cha kimantiki kilichosanidiwa katika kiwango cha kuzuia hakijaundwa kwa ajili ya kuongeza na kuondolewa mara kwa mara kwa vifaa. Kwa kweli, unapaswa kusanidi kiasi cha kimantiki kwenye kiwango cha kuzuia mara moja, ukikabidhi kwa mfumo wa faili, na kisha usifanye chochote kingine nacho.
Zaidi ya hayo, mchanganyiko wa mifumo ndogo ya FS na LVM hairuhusu asili tofauti ya viendeshi vinavyotumika kujumlisha kiasi cha kimantiki. Kwa kweli, tuseme umekusanya kiasi cha kimantiki kutoka kwa HDD na SSD. Ya kwanza itahitaji kutenganishwa, wakati ya mwisho haitafanya hivyo. Utahitaji kutoa ombi la kutupa la pili, wakati la kwanza halitafanya, na kadhalika. Walakini, uteuzi kama huo ni ngumu sana kufikia na mchanganyiko huu.
Kumbuka kuwa kuunda LVM yako mwenyewe kwenye mfumo wa faili haiboresha hali hiyo sana. Kwa kweli, kwa kufanya hivyo, unaondoa kwa ufanisi uwezekano wa kuiboresha katika siku zijazo. Hii ni mbaya sana. Aina tofauti za anatoa zinaweza kukaa kwenye mashine moja. Na ikiwa mfumo wa faili hautofautishi kati yao, nani atafanya?
Tatizo jingine linajificha kwenye mifumo ya faili inayoitwa "Andika-Popote" (hii pia ni pamoja na Reiser4, ikiwa ulibainisha muundo unaofaa wa ununuzi wakati wa kuweka). Mifumo kama hiyo ya faili lazima itoe zana zenye nguvu zaidi za utenganishaji. Kidhibiti cha sauti cha kiwango cha chini hakisaidii hapa, lakini kinazuia tu. Shida ni kwamba ukiwa na meneja kama huyo, mfumo wako wa faili utahifadhi ramani ya bure ya kifaa kimoja tu—kile kipeperushi. Kwa hivyo, unaweza tu kutenganisha kifaa cha kawaida. Hii ina maana kwamba mvunjaji wako atakuwa akifanya utumwa kwa muda mrefu kwenye nafasi kubwa iliyounganishwa ya anwani pepe.
Iwapo una watumiaji wengi wanaofanya ubatilishaji nasibu, manufaa ya kivunjaji kama hicho yatapuuzwa. Mfumo wako utapungua bila shaka, na hutaachwa bila chochote isipokuwa utambuzi wa kukatisha tamaa wa "muundo uliovunjika." Defragmenters nyingi zinazofanya kazi kwenye nafasi moja ya anwani zitaingiliana tu. Ni jambo tofauti kabisa ikiwa utadumisha ramani tofauti isiyolipishwa ya kuzuia kwa kila kifaa halisi. Hii itakuruhusu kusawazisha kwa ufanisi mchakato wa kugawanyika.
Lakini hii inaweza tu kufanywa na meneja wa kiwango cha juu cha mantiki. Mifumo ya faili ya ndani iliyo na wasimamizi kama hao haikuwepo hapo awali (angalau, sijui yoyote). Mifumo ya faili za mtandao pekee (kama vile GlusterFS) ilikuwa na wasimamizi kama hao. Mfano mwingine muhimu sana ni matumizi ya kuangalia uadilifu wa kiasi (fsck). Ikiwa utahifadhi ramani 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.
Zaidi ya hayo, wasimamizi wa kiwango cha chini hawatakuruhusu kuunda vijipicha kamili. Ukiwa na mifumo ya faili ya LVM na ZFS, unaweza kupiga picha za ndani pekee, sio za kimataifa. Vijipicha vya ndani hukuruhusu tu kurejesha utendakazi wa faili mara moja. Uendeshaji na ujazo wa kimantiki (kuongeza na kuondoa vifaa) hautarejeshwa. Hebu tuangalie mfano. Wakati fulani kwa wakati, unapokuwa na kiasi cha mantiki kinachojumuisha vifaa viwili, A na B, vyenye faili 100, unachukua picha ya S ya mfumo na kisha kuunda faili nyingine mia.
Baada ya hayo, unaongeza kifaa C kwenye sauti yako, na hatimaye, kurejesha mfumo wako ili kupiga picha S. Swali: kiasi chako cha kimantiki kina faili ngapi na vifaa baada ya kurudishwa hadi S? Kama unavyoweza kukisia, kutakuwa na faili 100, lakini kutakuwa na vifaa vitatu-hizi ni vifaa sawa A, B, na C, ingawa wakati picha iliundwa, mfumo ulikuwa na vifaa viwili tu (A na B). Uendeshaji wa kuongeza kifaa C haukurejeshwa nyuma, na ikiwa sasa utaondoa kifaa C kwenye kompyuta, kitaharibu data yako. Kwa hiyo kabla ya kuiondoa, utahitaji kwanza kufanya operesheni ya gharama kubwa ya kuondoa kifaa kutoka kwa kiasi cha mantiki na kusawazisha upya, ambayo itasambaza data zote kutoka kwa kifaa C hadi vifaa vya A na B. Hata hivyo, ikiwa mfumo wako wa faili uliunga mkono snapshots za kimataifa, kusawazisha vile hakutakuwa muhimu, na baada ya kurejesha papo hapo kwa S, unaweza kuondoa kifaa C kutoka kwa kompyuta kwa usalama.
Kwa hiyo, uzuri wa snapshots za kimataifa ni kwamba zinakuwezesha kuepuka kuondolewa kwa gharama kubwa (kuongeza) kwa kifaa kutoka (hadi) kiasi cha mantiki kilicho na kiasi kikubwa cha data (ikizingatiwa, bila shaka, unakumbuka kuchukua picha ya mfumo wako kwa wakati unaofaa). Kama ukumbusho, kuunda vijipicha na kurejesha mfumo wa faili kwao ni shughuli za papo hapo. Unaweza kujiuliza: inawezekanaje kutendua operesheni mara moja kwa kiasi cha kimantiki ambacho kilikuchukua siku tatu? Naam, inawezekana! Isipokuwa mfumo wako wa faili umeundwa ipasavyo. Nilikuja na wazo la "picha za 3D" miaka mitatu iliyopita, na mwaka jana niliweka hati miliki ya mbinu hii.
Jambo linalofuata ambalo mifumo ya faili za ndani inapaswa kujifunza kutoka kwa mifumo ya faili za mtandao ni kuhifadhi metadata kwenye vifaa tofauti, kama vile mifumo ya faili za mtandao huihifadhi kwenye mashine tofauti (zinazojulikana kama seva za metadata). Baadhi ya programu hufanya kazi kwa kutumia metadata, na programu hizi zinaweza kuharakishwa kwa kiasi kikubwa kwa kuhifadhi metadata kwenye hifadhi za gharama kubwa na zenye utendakazi wa hali ya juu. Ukiwa na mfumo wa faili na LVM, hautaweza kuchagua sana: LVM haijui ni nini kwenye kizuizi unachokabidhi (data au metadata).
Utekelezaji wa LVM yako ya kiwango cha chini katika mfumo wa faili hautakupa nguvu nyingi juu ya mfumo wa faili na mchanganyiko wa LVM, lakini unachoweza kufanya vizuri sana ni kuunganisha mfumo wa faili kiasi kwamba inakuwa vigumu kufanya kazi na msimbo wake. ZFS na Btrfs, ambazo zilikimbilia kwenye vifaa dhahania, ni mifano wazi ya jinsi ukiukaji wa kuweka tabaka unavyoharibu mfumo kiusanifu. Hivyo, nini uhakika wangu? Jambo ni kwamba haupaswi kujenga LVM yako ya kiwango cha chini katika mfumo wa faili. Badala yake, unapaswa kujumlisha vifaa katika viwango vya kimantiki kwa kiwango cha juu, kama mifumo mingine ya faili za mtandao hufanya na mashine tofauti (nodi za kuhifadhi). Kwa kweli, wanaifanya vibaya sana kwa sababu ya utumiaji wa algorithms duni.
Mifano ya algoriti za kutisha ni pamoja na mtafsiri wa DHT katika mfumo wa faili wa GlusterFS na kinachojulikana kama ramani ya CRUSH katika mfumo wa faili wa Ceph. Hakuna algorithms yoyote niliyoona iliniridhisha katika suala la urahisi na uboreshaji mzuri. Kwa hivyo ilinibidi kukumbuka algebra yangu na kuvumbua kila kitu mwenyewe. Mnamo 2015, nilipokuwa nikijaribu kuweka safu juu ya vitendaji vya heshi, nilikuja na kuweka hati miliki kitu ambacho kinanifaa. Sasa naweza kusema kwamba jaribio langu la kutekeleza haya yote kwa vitendo lilifanikiwa. Sioni maswala yoyote ya kuongezeka na mbinu mpya.
Ndio, kila subvolume itahitaji muundo tofauti-kama superblock kwenye kumbukumbu. Hiyo inatisha kweli? Sijui ni nani "atachemsha bahari" na kuunda kiasi cha kimantiki cha mamia ya maelfu au vifaa zaidi kwenye mashine moja ya ndani. Ikiwa mtu yeyote angeweza kunielezea hili, ningeshukuru sana. Kwa sasa, ni uzushi tu wa uuzaji kwangu.
Je, mabadiliko katika mfumo mdogo wa kifaa cha kuzuia kernel (kwa mfano, kuibuka kwa blk-mq) yameathiri vipi mahitaji ya utekelezaji wa mfumo wa faili?
Hawakuwa na athari. Sijui nini kitatokea kwa safu ya kuzuia ambayo ingelazimu kubuni mfumo mpya wa faili. Muunganisho kati ya mifumo ndogo hii ni duni sana. Kutoka upande wa dereva, athari pekee kwenye mfumo wa faili inapaswa kuwa kuanzishwa kwa aina mpya za gari, ambazo safu ya kuzuia itakabiliana kwanza, na kisha mfumo wa faili (kwa reiser4, hii itamaanisha kuanzishwa kwa programu-jalizi mpya).
Je, kuibuka kwa aina mpya za hifadhi (kama vile SMR au utumizi mkubwa wa SSD) kunamaanisha changamoto mpya za muundo wa FS?
Ndiyo. Na hizi ni motisha za kawaida kwa maendeleo ya mfumo wa faili. Changamoto zinaweza kuwa tofauti na zisizotarajiwa kabisa. Kwa mfano, nimesikia juu ya anatoa ambapo utendaji wa I/O unategemea sana saizi ya sehemu ya data na urekebishaji wake. Katika Linux, ambapo saizi ya kizuizi cha mfumo wa faili haiwezi kuzidi saizi ya ukurasa, hifadhi kama hiyo haitaonyesha uwezo wake kamili kwa chaguo-msingi. Walakini, ikiwa mfumo wako wa faili umeundwa ipasavyo, kuna nafasi ya kufinya mengi zaidi kutoka kwake.
Je, ni watu wangapi mbali na wewe wanaofanya kazi kwa sasa na msimbo wa Reiser4?
Chini ya ningependa, lakini pia sijapata uhaba mkubwa wa rasilimali. Nina furaha zaidi na kasi ya maendeleo ya Reiser4. Sipangi kuharakisha mambo—hili si eneo sahihi. Hapa, "polepole na thabiti hushinda mbio!" Mfumo wa kisasa wa faili ndio mfumo mgumu zaidi wa kernel, na maamuzi duni ya muundo yanaweza kuharibu miaka ya kazi inayofuata.
Wakati wa kuuliza watu wa kujitolea kutekeleza jambo fulani, mimi huhakikisha kwamba juhudi zao hakika zitasababisha matokeo sahihi ambayo yanaweza kutumika kwa madhumuni makubwa. Kama unavyoelewa, dhamana kama hizo haziwezi kuwa nyingi na mara moja. Wakati huo huo, siwezi kustahimili "watendaji" ambao wanatangaza bila aibu "vipengele" vya programu ambayo ni dhahiri haiwezi kutumika, ikidanganya mamia ya watumiaji na wasanidi programu, na bado kukaa na kutabasamu kwenye mikutano ya kernel.
Je, kuna kampuni yoyote iliyoonyesha nia ya kusaidia maendeleo ya Reiser4?
Ndio, kulikuwa na matoleo kama haya, pamoja na kutoka kwa muuzaji mkuu. Lakini kufanya hivyo, ningelazimika kuhamia nchi nyingine. Kwa bahati mbaya, sina umri wa miaka 30 tena, na siwezi tu kuinuka na kuondoka kwenye tone la kofia.
Ni vipengele vipi vinakosekana kutoka kwa Reiser4 sasa?
Kitendakazi cha kubadilisha ukubwa kwa kiasi rahisi, sawa na kinachopatikana katika ReiserFS (v3), hakipo. Operesheni za faili zilizo na bendera ya DIRECT_IO pia zitasaidia. Kwa kuongezea, itakuwa nzuri kuweza kugawanya kiasi katika "subvolumes za semantic," ambazo hazina saizi maalum na zinaweza kuwekwa kama viwango tofauti. Kazi hizi ni nzuri kwa wanaoanza wanaotafuta kufanya mikono yao kuwa chafu.
Mwishowe, ningependa kuona idadi ya kimantiki ya mtandao na utekelezaji rahisi na usimamizi (algorithms za kisasa tayari zinaruhusu hii). 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 kwa sababu ya ukosefu wa maoni kati ya watengenezaji wa teknolojia zingine za mfumo wa faili.
Je, kila kitu ambacho kinaweza kuhitajika kinaweza kutekelezwa kwa kutumia programu-jalizi?
Ikiwa tunazungumza tu katika suala la miingiliano na programu-jalizi (moduli) zinazozitekeleza, sio hivyo tu. Lakini ikiwa pia tutaanzisha uhusiano kwenye miingiliano hii, basi, pamoja na kila kitu kingine, tutakuwa na dhana za polimafimu za hali ya juu, ambazo tunaweza kufanya nazo. Hebu wazia dhahania kufungia mfumo wa wakati wa kutekeleza unaolengwa na kitu, kubadilisha thamani ya kielekezi cha maagizo ili kuelekeza kwenye programu-jalizi tofauti inayotekelezea kiolesura sawa cha X, na kisha kuachia mfumo ili uweze kuendelea na utekelezaji.
Ikiwa mtumiaji wa mwisho hatagundua "badala" hii, basi tunasema mfumo una upolimishaji wa mpangilio sifuri kwenye kiolesura cha X (au mfumo unatofautiana katika kiolesura cha X, ambacho ni kitu kimoja). Ikiwa sasa huna tu seti ya miingiliano lakini pia uhusiano kati yao (grafu ya kiolesura), basi unaweza kuanzisha polimafimu za hali ya juu ambazo zina sifa ya utofauti wa mfumo katika "ujirani" wa kiolesura fulani. Nilianzisha uainishaji kama huo muda mrefu uliopita, lakini kwa bahati mbaya, sikuwahi kuichapisha.
Kwa hiyo, kwa kutumia programu-jalizi na polymorphisms hizi za juu, unaweza kuelezea kipengele chochote kinachojulikana, pamoja na "kutabiri" wale ambao hawajawahi hata kutajwa. Sijaweza kudhibitisha hili kwa ukali, lakini sijui mfano wa kulinganisha bado. Kwa kweli, swali hili linanikumbusha "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 kwa kernel kuu? Je, kumekuwa na machapisho yoyote kuhusu usanifu wa mfumo huu wa faili, kama ulivyotaja kwenye mahojiano ya mwisho? Je, unadhani suala hili lina umuhimu gani?
Kwa kweli, tumekuwa tukiomba kujumuishwa katika njia kuu kwa miaka mitatu. Maoni ya mwisho ya Reiser kwenye uzi wa umma ambapo alitoa ombi la kujumuishwa lilibaki bila kujibiwa. Kwa hivyo maswali yoyote zaidi sio kwetu. Binafsi, sielewi kwa nini tunahitaji "kuunganisha" katika mfumo maalum wa uendeshaji. Linux sio mahali pekee kwetu. Kwa hivyo, kuna hazina tofauti na bandari kadhaa za mifumo tofauti ya uendeshaji. Mtu yeyote anayehitaji anaweza kuiga bandari inayofaa na kufanya chochote anachotaka nayo (ndani ya leseni, bila shaka). Na ikiwa mtu haihitaji, hiyo sio shida yangu. Ninapendekeza kwamba hii inahitimisha suala la "kuikuza kwenye kinu kuu cha Linux."
Machapisho juu ya usanifu wa FS yanafaa, lakini hadi sasa nimepata tu wakati wa matokeo yangu mapya, ambayo ninazingatia 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 bila uthibitisho huchukuliwa kuwa fomu mbaya. Ikiwa ningethibitisha kwa ukali au kukanusha madai fulani juu ya usanifu wa FS, mrundikano unaosababishwa ungekuwa mgumu sana kupita. Nani anahitaji hiyo? Labda hiyo ndiyo sababu kila kitu kinasalia katika hali yake ya zamani-msimbo wa chanzo na maoni yake.
Ni nini kipya katika Reiser4 katika miaka michache iliyopita?
Utulivu uliosubiriwa kwa muda mrefu hatimaye umeonekana. Mojawapo ya mwisho kushindwa ilikuwa mdudu unaosababisha saraka "zisizoweza kufutwa". Shida ilikuwa kwamba ilijidhihirisha tu katika muktadha wa migongano ya hashi ya jina na maingizo maalum ya saraka ndani ya nodi ya mti. Hata hivyo, bado siwezi kupendekeza Reiser4 kwa matumizi ya uzalishaji: hii inahitaji kazi fulani na ushirikiano amilifu na wasimamizi wa mfumo wa uzalishaji.
Hatimaye nimeweza kutekeleza wazo la muda mrefu: mifano mingi ya shughuli. Hapo awali, Reiser4 iliunga mkono tu modeli moja ya ununuzi, yenye msimbo mgumu, mfano wa McDonald-Reiser. Hii ilizua changamoto za muundo. Hasa, muhtasari hauwezekani katika muundo huu wa muamala—zingepotoshwa na kijenzi cha "OVERWRITE SET" cha atomi. Reiser4 sasa inasaidia miundo mitatu ya shughuli. Katika mojawapo yao (Andika-Popote), sehemu ya OVERWRITE SET ya atomi inajumuisha tu kurasa za mfumo (picha za bitmap za diski, n.k.), ambazo haziko chini ya snapshots (tatizo la kuku-na-yai).
Kwa hivyo snapshots sasa zinaweza kutekelezwa kwa njia bora. Katika muundo mwingine wa muamala, kurasa zote zilizorekebishwa zimejumuishwa tu kwenye OVERWRITE SET (yaani, kimsingi ni uandishi safi). Mfano huu ni wa wale ambao walilalamika juu ya kugawanyika kwa haraka kwa sehemu za Reiser4. Sasa, na modeli hii, kizigeu chako hakitagawanyika haraka kuliko ReiserFS (v3). Mifano zote tatu zilizopo, pamoja na baadhi ya tahadhari, huhakikisha atomicity ya uendeshaji, lakini mifano ambayo hupoteza atomiki na kuhifadhi uadilifu wa kizigeu pia inaweza kuwa muhimu. Aina kama hizo zinaweza kuwa muhimu kwa kila aina ya programu (database, nk) ambazo tayari zinabeba baadhi ya kazi hizi. Itakuwa rahisi sana kuongeza mifano hii kwa Reiser4, lakini sijafanya hivyo kwa sababu hakuna mtu aliyeniuliza, na mimi binafsi siihitaji.
Cheki za metadata zimeonekana, na hivi majuzi niliziongezea na vioo "vya bei ya chini" (bado haijatulia). Ikiwa ukaguzi wa kizuizi utashindwa, Reiser4 husoma mara moja kizuizi kinacholingana kutoka kwa kifaa cha nakala. Kumbuka kuwa ZFS na Btrfs haziwezi kufanya hivi; muundo wao hauruhusu. Katika matukio hayo, unapaswa kuendesha mchakato maalum wa skanning background inayoitwa "scrub" na usubiri kufikia kizuizi cha matatizo. Watayarishaji wa programu kwa njia ya mfano huita hatua kama hizo "kazi za kufanya kazi."
Na mwishowe, idadi kubwa ya kimantiki imetokea, ikitoa kila kitu ambacho ZFS, Btrfs, safu ya kuzuia, na michanganyiko ya FS+LVM haiwezi tu—kuongeza kiwango sambamba, kigawa anwani cha diski O(1), na uhamishaji wa data wazi kati ya kiasi kidogo. Mwisho pia unasaidiwa na kiolesura cha mtumiaji. Sasa unaweza kuhamisha data motomoto kwa urahisi hadi kwenye hifadhi yenye utendaji wa juu zaidi katika sauti yako.
Zaidi ya hayo, inawezekana kufuta kwa haraka kurasa zozote chafu kwenye kiendeshi kama hicho, kuharakisha kwa kiasi kikubwa programu ambazo mara nyingi huita fsync(2). Ninapaswa kutambua kuwa utendakazi wa safu ya kuzuia, inayoitwa bcache, haitoi aina hii ya kubadilika hata kidogo. Kiasi kipya cha kimantiki kinatokana na algoriti zangu (hati miliki husika zipo). Programu tayari ni thabiti kabisa; unaweza kujaribu, kupima utendaji, nk. Usumbufu pekee ni kwamba kwa sasa unahitaji kusasisha usanidi wa kiasi na kuihifadhi mahali fulani.
Nimeweza kutekeleza mipango yangu takriban asilimia 10 hadi sasa. Walakini, nimeweza kukamilisha kile nilichozingatia kuwa kazi ngumu zaidi: kuunganisha kiasi cha kimantiki na utaratibu wa flash ambao hufanya vitendo vyote vilivyoahirishwa katika reiser4. Hii yote bado iko kwenye tawi la majaribio la "format41".
Je, Reiser4 hupita xfstests?
Angalau ilinifanyia nilipokuwa nikitayarisha toleo la mwisho.
Inawezekana kimsingi kufanya Reiser4 mfumo wa faili wa mtandao (nguzo) kwa kutumia programu-jalizi?
Inawezekana, na hata ni lazima! Ikiwa utaunda mfumo wa faili wa mtandao kulingana na mfumo wa faili wa ndani ulioundwa vizuri, matokeo yatakuwa ya kuvutia kweli! Sijaridhishwa na safu ya uhifadhi ya nyuma ya mifumo ya kisasa ya faili za mtandao, ambayo inatekelezwa kwa kutumia mfumo wowote wa faili wa ndani. Uwepo wa safu hii haufai kabisa. Mfumo wa faili wa mtandao unapaswa kuingiliana moja kwa moja na safu ya kuzuia na usihitaji mfumo wa faili wa ndani ili kuunda faili za huduma za ziada!
Kwa ujumla, kugawanya mifumo ya faili ndani ya ndani na mtandao ni kosa. Iliibuka kutokana na kutokamilika kwa algorithms iliyotumiwa miaka thelathini iliyopita, ambayo hakuna chochote kilichopendekezwa. Hii pia ndiyo sababu ya kuibuka kwa wingi wa vipengele vya programu zisizohitajika (huduma mbalimbali, nk). Kwa kweli, kunapaswa kuwa na mfumo mmoja tu wa faili, unaojumuisha moduli ya kernel na seti ya huduma za watumiaji zilizowekwa kwenye kila mashine-nodi ya nguzo. Mfumo huu wa faili ni wa ndani na mtandao. Na hakuna zaidi!
Ikiwa na Reiser4 ndani LinuxKama hakuna kinachotokea, ningependa kupendekeza 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 tutapata lugha ya pamoja na watengenezaji”)?
Kwa hivyo, kama tulivyogundua, tayari tunafanya vizuri na Linux: kuna bandari iliyojitolea, inayofanya kazi ya Reiser4 kwa ajili yake, sehemu ya tawi kuu la hazina yetu. Na sijasahau kuhusu FreeBSD! Jisikie huru kuipendekeza! Niko tayari kufanya kazi kwa karibu na mtu yeyote anayejua mambo ya ndani na nje ya FreeBSD. Kwa njia, ninachopenda sana kuhusu jumuiya yao ni kwamba maamuzi hufanywa na bodi inayozunguka ya wataalam wa kujitegemea, ambayo haina uhusiano wowote na puffery ya takwimu moja, ya kudumu.
Unaipa jamii ya watumiaji kiwango gani? Linux Je, imekuwa "pop" zaidi leo?
Kwa kuzingatia safu yangu ya kazi, ni ngumu sana kwangu kutathmini hii. Mara nyingi mimi hupata watumiaji na ripoti za hitilafu na maombi ya kurekebisha sehemu. Watumiaji ni kama watumiaji. Baadhi ni wajuzi zaidi, wengine chini sana. Kila mtu anatendewa kwa usawa. Kweli, ikiwa mtumiaji atapuuza maagizo yangu, basi, nisamehe: Nitayapuuza pia.
Je, inawezekana kutabiri mabadiliko ya mifumo ya faili katika kipindi cha miaka mitano hadi kumi ijayo? Je, unafikiri ni changamoto gani kuu zinazowakabili wasanidi wa mfumo wa faili?
Ndiyo, si vigumu kufanya utabiri kama huo. Hakujakuwa na maendeleo yoyote ya mifumo ya faili kwenye nafasi ya juu ya mkondo kwa muda mrefu. Inaonekana tu kuwa inatokea. Watengenezaji wa mfumo wa faili wa ndani wanakabiliwa na matatizo yanayohusiana na muundo mbaya. Tahadhari inapangwa hapa. Sichukulii kinachojulikana kama "hifadhi," "iliyosafishwa," na msimbo wa uhamishaji kuwa maendeleo. Na sichukulii kutoelewana kunakoitwa "Btrfs" kuwa ni maendeleo kwa sababu ambazo tayari nimeshazielezea.
Kila kiraka hufanya shida zake kuwa mbaya zaidi. Na daima kuna aina fulani ya "wainjilisti" ambao "hufanya kazi." Hawa wengi ni watoto wa shule na wanafunzi wanaoruka mihadhara. Hebu fikiria: toleo lake linafanya kazi, lakini la profesa halifanyi kazi. Ni msukumo ulioje wa adrenaline! Madhara makubwa zaidi, kwa maoni yangu, yanatokana na "wafanyao-wewe-mwenyewe" ambao hukimbilia kwa shauku kuweka vipengele vya miujiza ya Btrfs kwa kila aina ya safu kama vile systemd, docker, na kadhalika-tayari inaanza kuonekana kama metastasis.
Hebu sasa tujaribu kufanya utabiri wa miaka mitano hadi kumi. Tayari nimeelezea kwa ufupi kile tutakuwa tukifanya katika Reiser4. Changamoto kuu kwa watengenezaji wa mfumo wa faili wa eneo la juu itakuwa (ndiyo, tayari ni) kutowezekana kwa kufanya kazi nzuri kwa riziki. Bila mawazo yoyote ya kuhifadhi data, wataendelea kujaribu kubandika VFS, XFS, na ext4. Hali ya VFS ni ya kuchekesha haswa dhidi ya hali hii, inakumbusha hali ya kisasa ya mgahawa isiyo na mpishi na hakuna matarajio ya moja.
Sasa, msimbo wa VFS hufunga kurasa nyingi za kumbukumbu bila masharti kwa wakati mmoja na kuomba mfumo wa faili wa msingi kufanya kazi juu yake. Hii ilianzishwa ili kuboresha utendaji wa Ext4 wakati wa shughuli za kufuta, lakini, kama unavyoweza kuelewa kwa urahisi, kufunga kwa wakati mmoja hakuendani kabisa na mifumo ya juu ya miamala. Hii ina maana kwamba huwezi kuongeza tu usaidizi wa aina fulani ya mfumo mahiri wa faili kwenye kiini. Sijui mambo yakoje katika maeneo mengine. LinuxLakini linapokuja suala la mifumo ya faili, maendeleo yoyote hapa hayaendani na sera ambazo Torvalds anafuatilia (miradi ya kitaaluma hufukuzwa, na matapeli ambao hawajui mti B ni nini hupewa sifa isiyo na mwisho). Kwa hivyo, njia ya kuoza polepole imewekwa. Bila shaka, watajitahidi kadri wawezavyo kupitisha hili kama "maendeleo."
Ifuatayo, mfumo wa faili "walinzi," wakigundua kuwa hifadhi pekee haifai sana, itajaribu mkono wao kwa ubia wa faida zaidi. Hizi kawaida huhusisha mifumo ya faili iliyosambazwa na uboreshaji. Labda watapeleka ZFS ya kisasa hadi mahali pengine ambapo haipo. Lakini kama mifumo yote ya juu ya faili, ni kama mti wa Krismasi: wakati unaweza kunyongwa vipande vichache vya ziada juu, huwezi kwenda ndani zaidi. Ninakiri kwamba kujenga mfumo mzito wa biashara na ZFS inawezekana, lakini kwa kuwa tunajadili siku zijazo, naweza kusema kwa majuto tu kwamba ZFS haina tumaini katika suala hili: kwa vifaa vyao vya kawaida, watu hawa wamekata oksijeni kwa maendeleo zaidi kwao wenyewe na vizazi vijavyo. ZFS ndio habari ya jana. Na ext4 na XFS sio siku moja kabla ya jana tena.
Inafaa kutaja kando dhana iliyozungumziwa sana ya "Linux mfumo wa faili wa kizazi kijacho." Huu ni mradi wa kisiasa na uuzaji kabisa, ulioundwa ili kuweza, kwa kusema, "kuhatarisha mustakabali wa mifumo ya faili" katika Linux kwa wahusika maalum. Jambo ni kwamba, ilikuwa Linux Ilikuwa "kwa ajili ya kujifurahisha tu." Sasa, kimsingi ni mashine ya kutengeneza pesa. Pesa hupatikana kwa kila kitu. Kwa mfano, kuunda bidhaa nzuri ya programu ni vigumu sana, lakini "watengenezaji" werevu wamegundua kwa muda mrefu kwamba hakuna haja ya kujitahidi hata kidogo: hata programu ambazo hazipo, zilizotangazwa na kutangazwa katika kila aina ya matukio ya umma, zinaweza kuuzwa kwa mafanikio—jambo kuu ni kuwa na vipengele vingi kwenye slaidi za uwasilishaji.
Mifumo ya faili ni bora kwa hili, kwani unaweza kujadili kwa urahisi kusubiri kwa miaka kumi kwa matokeo. Na ikiwa mtu yeyote baadaye analalamika juu ya ukosefu wa matokeo, hawaelewi mifumo ya faili! Inakumbusha mpango wa piramidi: juu ni wadanganyifu ambao walianza yote, na kisha wachache wenye bahati ambao "huvuna gawio," yaani, kupokea fedha kwa ajili ya maendeleo, kupata kazi za usimamizi wa malipo ya juu, kufanya jina kwa wenyewe kwenye mikutano, na kadhalika.
Halafu wanakuja wale ambao "hawana bahati": watahesabu hasara zao, kukabiliana na matokeo ya kupeleka programu isiyoweza kutumika katika uzalishaji, na kadhalika. Kuna wengi zaidi wao. Na chini ya piramidi ni wingi mkubwa wa watengenezaji "kukata" msimbo usio na maana. Wao ndio wapotezaji wakubwa, kwa sababu wakati uliopotea hauwezi kurejeshwa. Piramidi kama hizo zina faida kubwa kwa Torvalds na wasaidizi wake. Na zaidi ya piramidi hizi, ni bora kwao. Ili mafuta ya piramidi kama hizo, chochote kinaweza kukubalika ndani ya msingi. Bila shaka, wanadai kinyume hadharani. Lakini sihukumu kwa maneno, bali kwa matendo.
Kwa hivyo, "mustakabali wa mifumo ya faili ya Linux" ni programu nyingine inayosisimuliwa sana, lakini isiyotumika vizuri. Baada ya Btrfs, kuna uwezekano mkubwa kwamba "mustakabali" huu utabadilishwa na Bcachefs, ambayo ni jaribio lingine la kuchanganya faili. Linux Safu ya vitalu yenye mfumo wa faili (mfano mbaya unaambukiza). Na cha kufurahisha ni kwamba ina matatizo sawa na Btrfs. Nilikuwa nimeshuku hili kwa muda mrefu, na kisha sikuweza kujizuia kutazama msimbo—na ni kweli!
Waandishi wa Bcachefs na Btrfs, wakati wa kuunda mifumo yao ya faili, walitumia tena msimbo wa chanzo wa watu wengine, wakielewa kidogo. Hali hiyo inawakumbusha sana mchezo wa watoto "simu." Na ninaweza kufikiria jinsi nambari hii itaingizwa kwenye kernel. Hakuna mtu atakayegundua "mitego" (kila mtu ataikanyaga baadaye). Baada ya mabishano mengi juu ya mtindo wa uandishi, mashtaka ya ukiukwaji usiopo, na kadhalika, hitimisho litafikiwa juu ya "uaminifu" wa mwandishi, jinsi "wanaingiliana" na watengenezaji wengine, na jinsi wanavyoweza kuuza haya yote kwa mashirika.
Matokeo ya mwisho hayatavutia mtu yeyote. Miaka ishirini iliyopita, inaweza kuwa, lakini sasa maswali yanatolewa tofauti: itawezekana kuendeleza hili ili watu fulani wapate ajira ndani ya miaka kumi ijayo? Na kuuliza juu ya matokeo ya mwisho, ole, sio jambo lililofanywa.
Kwa ujumla, ningeshauri sana dhidi ya kuanza kuvumbua mfumo wako wa faili kutoka mwanzo. Hata uwekezaji mkubwa wa kifedha hautatosha kufikia kitu cha ushindani katika miaka kumi. Kwa kweli, ninazungumza juu ya miradi mikubwa, sio iliyokusudiwa ujumuishaji wa kernel. Kwa hivyo, njia mwafaka zaidi ya kujitengenezea jina ni kujiunga na juhudi za maendeleo halisi, kama zetu. Hii si rahisi, bila shaka, lakini ndivyo ilivyo kwa mradi wowote wa juu.
Kwanza, utahitaji kutatua shida nitakayoleta. Kisha, nikiamini umakini wako, nitaanza kusaidia. Kijadi, tunatumia tu maendeleo yetu wenyewe. Isipokuwa ni kanuni za ukandamizaji na baadhi ya vipengele vya heshi. Hatuwatumi wasanidi programu kwenye mikutano na kisha kukaa na kuchanganya mawazo ya watu wengine ("labda kitu kitafanikiwa"), kama ilivyo kawaida katika uanzishaji mwingi.
Tunatengeneza algoriti zote sisi wenyewe. Kwa sasa, ninavutiwa na vipengele vya aljebra na mchanganyiko wa sayansi ya kuhifadhi data. Hasa, sehemu zenye kikomo, asymptotiki, na ukosefu wa usawa. Pia kuna kazi kwa watengenezaji programu wa kawaida, lakini lazima nikuonye mara moja: mapendekezo yote ya "kuangalia mfumo mwingine wa faili na kufanya vivyo hivyo" yatapuuzwa. Viraka vinavyolenga ujumuishaji wa karibu na Linux kupitia mstari wa VFS.
Kwa hivyo, hatuna mitego yoyote, lakini tuna ufahamu wa wapi tunahitaji kwenda, na tuna uhakika kwamba huu ndio mwelekeo sahihi. Ufahamu huu haukuja kama mana kutoka mbinguni. Acha nikukumbushe kwamba tuna uzoefu wa miaka 29 nyuma yetu, mifumo miwili ya faili iliyoandikwa kutoka mwanzo, na huduma nyingi tu za kurejesha data. Na hiyo ni nyingi!
Chanzo: opennet.ru
