Përkthim i mendimeve nga Theodore Ts'o, krijuesi i sistemit të skedarëve Ext4, rreth zhvillimit të ext4, sistemit të skedarëve BcacheFS dhe bërthamës Linux, ZFS, kodi i sjelljes dhe sistemet e skedarëve në përgjithësi:
Rreth zhvillimit të ext4.
Më shumë se gjysmë duzine njerëzish kontribuojnë në çdo version të kernelit ext4. Aktualisht, pjesën më të madhe të kohës sime e kaloj duke shqyrtuar kodin, duke ekzekutuar teste dhe duke përmirësuar aplikacionin e testimit.KVM,gce,qemu,android}-xfstests. Dhe unë mbështetem shumë te dy ose tre zhvillues të tjerë që punojnë në SUSE dhe IBM të cilët më ndihmojnë me rishikimet e kodit.
Rreth BcacheFS
Për të qenë të drejtë, bcachefs nuk është një projekt plotësisht solo - për shembull, Kent ishte autori i 72% të arnimeve midis lëshimeve të kernelit 6.11 dhe 6.12, ndërsa nga 103 arna ext4 gjatë së njëjtës periudhë kohore, unë isha autori saktësisht 0%. Kjo sepse unë besoj fuqishëm se programimi është një sport ekipor dhe puna ime si drejtuese teknike është të fuqizoj anëtarët e ext4 që të bëjnë çmos për të përmirësuar sistemin e skedarëve. Ne kemi konferenca javore dhe Darrick Wong, një zhvillues i vjetër i XFS dhe ish mirëmbajtësi i XFS, merr pjesë në këto konferenca - dhe unë kam qenë i njohur për ta ndihmuar atë me çështjet e testimit të XFS, dhe Darrick më ka ndihmuar me çështje të ndryshme të testimit ext4 dhe madje ka rishikuar disa arna ext4. Ne bashkëpunojmë me njëri-tjetrin dhe kjo është mirë.
Do t'ua lë të tjerëve të vendosin nëse duan t'i besojnë të dhënat e tyre dikujt që është një programues i vetmuar, i cili mund të jetë shumë më i talentuar se unë, por unë do t'ju jap një sugjerim - ju mund të "mashtroni" duke marrja e një ekipi për të zgjidhur problemin. Nuk duhet ta bëni vetëm. Sigurisht, për ta bërë këtë, ju duhet të dini se si të nxirrni më të mirën tek të tjerët dhe duhet të punoni së bashku. Dhe të qenit i sjellshëm me njëri-tjetrin në listat e postimeve nuk dëmton.
Rreth kernelit, CoC, veçorive dhe të ardhmes së ext4
Ext4 merr disa veçori të reja, por këto janë ato që kompanitë janë të gatshme të financojnë sepse kthimi i investimit (ROI) i zhvillimit të veçorisë ka kuptim nga një perspektivë kosto-përfitim. Për shembull, drejtoritë fscrypt dhe ato që nuk i kushtojnë rëndësi shkronjave të mëdha dhe të vogla ishin veçori që ishin të dobishme për Android dhe Chrome OS, dhe u financuan, të paktën pjesërisht, nga këto ekipe zhvillimi (Steam ishte gjithashtu i shqetësuar për palosjen e skedarëve dhe mbështeti një nga inxhinierët). Ne duam të shtojmë mbështetje për shkrimet e patransferuara sepse kjo do të përmirësojë performancën e bazës së të dhënave në pajisjet me bllok të emuluar të bazuara në cloud, ku mund të garantohen 16k shkrime atomike, duke eliminuar ruajtjen e dyfishtë në MySQL dhe PostgreSQL.
(Në fakt Amazon dhe Google mund ta bëjnë këtë në produktet e tyre DBMS duke bërë supozime se si funksionojnë Amazon EBS dhe Google Persistent Disk, por ne duam ta bëjmë këtë në një mënyrë më të përgjithshme që do të jetë më e mirëmbajtur në afat të gjatë). Është më pak seksi se gjërat si rilidhjet, por ROI është shumë më e lehtë për t'u justifikuar, edhe sepse kostot janë më të ulëta (më pak zhvillim, testim dhe punë kualifikimi për vendosjet e ndërmarrjeve) dhe sepse përfitimet janë shumë më të lehta për t'u llogaritur. Gjëra të tilla si "Unë mund të kursej koston e pagave të inxhinierëve të softuerit XX me kohë të plotë gjatë pesë viteve" janë shumë më të lehta për t'u bërë për këtë lloj funksioni produktiviteti.
Në të kundërt, reflinks janë argëtuese, por unë nuk kam qenë në gjendje të gjej një klient të gatshëm të paguajë kostot e zhvillimit ose një kompani që beson se klientët e tyre do të blejnë më shumë nga produkti i tyre nëse shtojnë reflinks në ext4. Kjo mund të tingëllojë tmerrësisht e korporatës, por ka një histori se si inxhinierët e ZFS filluan një projekt nga e para, pa kërkuar leje nga menaxhmenti ose pa marrë të dhëna nga shitjet, dhe i paraqitën Sunit atë që ishte efektivisht një fakt i kryer.
Tingëllon shkëlqyeshëm, por mos harroni se Sun përfundoi duke humbur para derisa u detyrua t'ia shiste veten një kompanie tjetër, dhe organizata inxhinierike që mbështeste ZFS nuk ekziston më. Rreth kohës kur u njoftua ZFS, unë isha i përfshirë në një studim në të gjithë kompaninë për të përcaktuar nëse kishte kuptim të investoja në veçoritë e sistemit të skedarëve për AIX dhe Linux — dhe arritëm në përfundimin se jo, kthimi i investimit është i vogël dhe veçoritë e reja të sistemit të skedarëve nuk do të çojnë në më shumë klientë që blejnë pajisje, softuerë ose sisteme IBM. IBM mund të ketë kaluar kohë të vështira, por është ende këtu, dhe Sun jo.
Në të njëjtën kohë, përfaqësues të disa Linux-kompanitë u bashkuan për të kuptuar se si Linux do të konkurrojë me ZFS. Ishte në këtë takim që u hodh ideja që btrfs do të ishte përgjigjja afatgjatë, dhe ext4 do të ishte zgjidhja afatshkurtër, e cila do të ofronte mbështetje për gjëra të tilla si ndryshimi i madhësisë live, numrat e blloqeve 64-bit dhe veçori të tjera që gjenden në sistemet operative tradicionale Legacy Unix që ext3 nuk i kishte.
Në atë takim, më kërkuan të përcaktoja se çfarë do të duhej për të krijuar një sistem skedari krejtësisht të ri. Bëra disa kërkime, duke parë se sa përpjekje u deshën për të krijuar sisteme skedarësh si GPFS dhe JFS të IBM, advf-të e Digitalb, dhe vlerësova se sa shumë iu desh Sun për të krijuar ZFS dhe për ta çuar atë sistem skedarësh në një gjendje gati për prodhim. Përgjigja që mora ishte afërsisht 100 vite-njeri, me një vlerësim të ulët prej 50 vite-njeri dhe një vlerësim të lartë prej 200 vite-njeri (por kjo ishte për GPFS, i cili ishte një sistem skedarësh i grumbulluar, dhe për këtë arsye shumë më kompleks).
E përmenda këtë në një takim dhe një inxhinier i lartë në Intel tha: “Jo, mos u tregoni drejtuesve për këtë, sepse ata nuk do ta miratojnë kurrë projektin! Thuaju që btrfs do të jetë gati për 18 muaj." Do t'ua lë njerëzve të vendosin se kur btrf-të do të arrijnë statusin "gati për sipërmarrje", veçanërisht për ato veçori të reja të avancuara seksi që synonin të konkurronin me ZFS, por nuk mendoj se është për debat që nuk ka kaluar 18 muaj. nga tani.
Edhe para se Sun të shpërbëhej, shumë nga kompanitë që dërguan përfaqësues në takim refuzuan që inxhinierët e tyre të merrnin pjesë në btrfs, gjë që, sigurisht, nuk ndihmoi. Por kjo ndoshta ndodhi sepse kompanitë janë organizata racionale që marrin vendimet e tyre në lidhje me kthimin e investimit, dhe financimi i një sistemi të ri skedarësh nuk kishte aq kuptim sa t'u tregohej njerëzve se çfarë Linux Do të ketë një përgjigje për ZFS-në.
Në retrospektivë, ndërsa ZFS kishte këto karakteristika vërtet të mira, ato nuk ishin të mjaftueshme për t'i bërë shumicën e përdoruesve të zgjidhnin Solaris në vend të blerjes së platformave x86 shumë më të lira dhe instalimit LinuxDhe kur Sun vendosi të provonte strategjinë OpenSolaris dhe Solaris x86, ishte tepër vonë. Efektet e rrjetit ishin të jashtëzakonshme dhe strategjia x86 nuk iu përgjigj pyetjes se si një kompani, Sun, mund të paguante pagat e të gjithë inxhinierëve super të talentuar që punonin në Solaris. Blerja e një serveri x86 për 5000 dollarë nuk ofron një kthim të lartë të shitjeve krahasuar me server SunFire E10k Sparc me vlerë 100000 dollarë, të cilin Sun e quajti "pika" në "dot Com".
Çështja është se inxhinieria në botën reale është një kompromis, dhe realitetet e biznesit janë pjesë e këtij shkëmbimi. Nuk kërkoj falje për faktin që zgjedh të ha ushqim dhe që dua të fitoj mjaftueshëm para për të dalë në pension një ditë. Dhe kjo, nga ana tjetër, do të thotë që unë duhet të kuptoj mirë se si i sjell vlerë punëdhënësit të paktën 10fishin e pagës sime. Nëse mund ta bëj këtë ndërkohë që ende punoj në burim të hapur dhe duke ndihmuar kompanitë e tjera të fitojnë para në mënyrë që ato të jenë të gatshme të kontribuojnë në ext4, mirë, kjo është pjesë e sfidës dhe pse më pëlqen të punoj në burim të hapur.
Dhe, duke u kthyer te Kodi i Sjelljes, do të them se pothuajse të gjithë mirëmbajtësit e sistemeve kryesore të skedarëve e mbështetën Kodin jo për ndonjë arsye të dobët liberale. Kjo sepse kemi nevojë për çdo inxhinier të gatshëm të kontribuojë në projektin tonë, dhe shumica prej nesh kanë parë njerëz që refuzuan të punonin në Linux dhe kaloi në sisteme të tjera operative (njoh një person që kaloi në Windows dhe ishte një zhvillues i vlefshëm i kernel-it Linux në IBM Linux Qendra e Teknologjisë) ose ka punuar në projekte të brendshme, por jo në asgjë që kërkonte ndërveprim me LKML, për shkak të mjedisit toksik të disa personave në listën e postimeve.
Në disa raste frika ishte e pabazë; për shembull, Linus po i bërtiste një zhvilluesi të vjetër i cili me të vërtetë duhet ta kishte njohur më mirë dhe që në shumicën e rasteve Linus e kishte takuar personalisht dhe ata kishin një marrëdhënie tashmë të krijuar. Problemi është se të ardhurit nuk e dinin këtë dhe kishin frikë - "po sikur Linus të më poshtërojë në publik në të njëjtën mënyrë që bëri me Steve", duke mos e kuptuar që në praktikë kjo nuk do të ndodhte. Kjo është arsyeja pse ne kemi CoC; kjo nuk është për ne inxhinierët e vjetër, por për të mbështetur inxhinierët më të rinj në ekipet tona, të cilët duam t'i trajnojmë për të na zëvendësuar në një moment kur është koha për të dalë në pension, ose kur goditemi nga një autobus, ose ndryshe largohemi nga kjo botë e vdekshme.
Mos harroni 50-100 vite punë që duhen për të krijuar një sistem skedarësh të gatshëm për përdorim në një mjedis ndërmarrjeje. Ne kemi nevojë për të gjithë inxhinierët që mund të marrim dhe shumë prej nesh bëjnë punë shtesë në kohën e lirë, sepse na intereson. Ndërtimi i një sistemi skedarësh me cilësi të lartë është një përpjekje ekipore dhe ne kemi nevojë për çdo inxhinier të talentuar që mund të marrim. Edhe nëse një inxhinier është një programues super 10x, nëse ai përfundon duke trembur një grup inxhinierësh të tjerë që mund të punojnë në testim, akordim të performancës, etj., thjesht nuk ia vlen të lejosh dikë të jetë budalla.
Burimi: opennet.ru
