Апублікавана другое інтэрв'ю з Эдуардам Шышкіным, распрацоўшчыкам файлавай сістэмы Reiser4.
Для пачатку нагадай, калі ласка, чытачам, дзе і кім ты працуеш.
Я працую на пасадзе Principal Storage Architect у кампаніі Huawei Technologies, German Research Center. У аддзеле віртуалізацыі займаюся рознымі аспектамі захоўвання дадзеных. Мая дзейнасць не звязана з канкрэтнай аперацыйнай сістэмай.
Ці каміціш ты зараз у асноўную галінку ядра?
Вельмі рэдка, і толькі калі гэта патрабуе мой працадаўца. Апошні раз гады тры назад я пасылаў патчы, якія дазваляюць падвысіць прапускную здольнасць для сховішчаў, расшаренных на хастах па пратаколе 9p (іншая назва гэтай справы – VirtFS). Тут трэба зрабіць адну важную заўвагу: хоць я і даўно працую побач з Лінукс, яго фанатам я ніколі не з'яўляўся, гэта значыць, «дыхаю роўна», як зрэшты і да ўсяго астатняга. У прыватнасці, калі я заўважыў нейкую загану, то магу ўказаць на яго максімум адзін раз. А так, каб потым за кімсьці хадзіць і ўгаворваць - такога не будзе.
Памятаецца, мінулым разам, дзесяць гадоў таму, ты даволі крытычна адклікаўся аб стылі распрацоўкі ядра. Ці памянялася з твайго (ці, магчыма, карпаратыўнага) пункта гледжання штосьці, супольнасць стала больш спагаднай ці не? Калі не, хто, па-твойму, у гэтым вінаваты?
Я так і не ўбачыў якіх-небудзь зрухаў у лепшы бок. Асноўная праблема супольнасці - гэта падмена навукі паліттэхналогіямі, персанальнымі адносінамі, меркаваннем большасці, папулізмам, парадамі «ўнутраных галасоў», гнілымі кампрамісамі, усім чым заўгодна акрамя навукі. Computer science, як ні круці, першым чынам дакладная навука. І калі хтосьці пачынае абвяшчаць для 2×2 сваё значэнне, выдатнае ад 4, пад сцягам "Linux way", або пад якім іншым, то акрамя шкоды гэта ці наўрад што прынясе.
Усе беды найперш ад некампетэнтнасці і неадукаванасці тых, хто прымае рашэнні. Калі кіраўнік некампетэнтны, ён не здольны прыняць аб'ектыўнае адэкватнае рашэнне. Калі ён да таго ж і бескультурны, ён не здольны знайсці кампетэнтнага спецыяліста, які дасць яму правільную параду. З вялікай верагоднасцю выбар упадзе на ашуканца, які гаворыць «з выгляду правільныя рэчы». Вакол некампетэнтных лідэраў-адзіночак заўсёды складаецца карумпаванае асяроддзе. Прычым, гісторыя не ведае выключэнняў на гэты конт, і супольнасць – яркае таму пацвярджэнне.
Як ты ацэньваеш прагрэс у распрацоўцы Btrfs? Гэтая ФС пазбавілася ад дзіцячых хвароб? Як ты яе для сябе пазіцыянуеш - як ФС «для дома» ці і для карпаратыўнага прымянення таксама?
Не пазбавілася. Усё тое, пра што я згадваў 11 гадоў таму, актуальна і дагэтуль. Адна з праблем Btrfs, якая робіць апошнюю непрыдатнай для сур'ёзных патрэб, - гэта праблема вольнага месца. Я ўжо не кажу пра тое, што карыстачу прапануецца бегчы ў краму за новым дыскам у сітуацыях, калі любая іншая ФС паказала б яшчэ процьму вольнага месца на раздзеле. Немагчымасць завяршыць аперацыю над лагічным томам з прычыны недахопу вольнага месца - гэта таксама не самае страшнае. Горш за ўсё тое, што непрывілеяваны карыстач амаль заўсёды можа за досыць кароткі час у абыход любых дыскавых квот пазбавіць усіх вольнага месца.
Выглядае гэта так (праверана для ядра Linux 5.12). На свежаінсталяванай сістэме запускаецца скрыпт, які ў цыкле стварае ў хатняй дырэкторыі файлы з вызначанымі імёнамі, запісвае ў іх дадзеныя па вызначаных зрушэннях і затым выдаляе гэтыя файлы. Праз хвіліну працы гэтага скрыпту нічога незвычайнага не адбываецца. Праз пяць хвілін порцыя занятага месца на раздзеле крыху павялічваецца. Праз дзве-тры гадзіны яна дасягае 50% (пры пачатковым значэнні 15%). А пасля пяці-шасці гадзін працы скрыпт валіцца з памылкай "няма вольнага месца на раздзеле". Пасля гэтага вы ўжо не ў стане запісаць на вашу частку нават 4К файл.
Адбываецца цікавая сітуацыя: вы нічога на падзел у выніку не запісалі, а ўсё вольнае месца (парадку 85%) кудысьці знікла. Аналіз часткі, падвергнутага такой атацы, пакажа мноства вузлоў дрэва, якія змяшчаюць усяго адзін айцем (аб'ект, забяспечаны ключом), памерам некалькі байт. Гэта значыць, кантэнт, які раней займаў 15% дыскавай прасторы апынуўся раўнамерна "размазаным" на ўсю частку так, што новы файл запісаць ужо няма куды, бо яго ключ больш за ўсіх існых, а вольныя блокі на падзеле скончыліся.
Прычым гэта ўсё адбываецца ўжо на базавай канфігурацыі Btrfs (без усякіх снапшотаў, сабвольюмов і інш.), і не мае значэння тое, як вы вырашылі захоўваць целы файлаў у той ФС (як «фрагменты» у дрэве, ці ж як экстэнты нефарматаваных блокаў) - канчатковы вынік будзе адзін і той жа.
Падвергнуць такому нападу астатнія файлавыя сістэмы з апстрыму вам не атрымаецца (што б вам там ні казалі). Прычыну праблемы я ўжо даўно патлумачыў: гэтае поўнае скрыўленне ў Btrfs паняцці B-дрэва, што робіць магчымым яго спантаннае ці наўмыснае выраджэнне. У прыватнасці, пры некаторых нагрузках ваша ФС падчас эксплуатацый будзе бесперапынна «развальвацца» і сама, без старонняй дапамогі. Зразумела, што разнастайныя «падціскаючыя» фонавыя працэсы выратуюць справу толькі на індывідуальных дэсктопах.
На калектыўных жа серверах зламыснік заўсёды будзе ў стане іх "апярэдзіць". Сістэмны адміністратар нават не зможа вызначыць, хто менавіта з яго здзекаваўся. Хутчэй за ўсё выправіць гэтую праблему ў Btrfs можна толькі аднавіўшы структуру рэгулярнага B-дрэва, г.зн. зноўку перапраектаваўшы дыскавы фармат і перапісаўшы істотную частку кода Btrfs. Гэта зойме 8-10 гадоў разам з адладкай пры ўмове, што распрацоўшчыкі выразна прытрымліваліся арыгінальных артыкулаў па адпаведных алгарытмах і структурам дадзеных, а не гулялі ў «сапсаваны тэлефон», як гэта прынята (і заахвочваецца) у «Linux way».
Сюды яшчэ трэба дадаць час, неабходны распрацоўшчыкам на тое, каб зразумець усё гэта. Вось тут ужо складаней. Ва ўсякім разе, 10 гадоў на разуменне ім не хапіла. Ну, а да гэтага можаце не спадзявацца на цуд. Яно не адбудзецца ў выглядзе опцыі мантавання "пра якую мы з вамі не ведалі", ці ў выглядзе патча, які прыгатаваць "усяго-то спраў". Для кожнага такога паспешлівага «выпраўлення» я прад'яўлю новы сцэнар зводу. B-дрэвы - гэта адна з маіх упадабаных тэм, і павінен сказаць, што вольнасці ў абыходжанні з сабой гэтыя структуры не церпяць!
Як я для сябе пазіцыяную Btrfs? Як нешта, што называцца файлавай сістэмай катэгарычна не можа, не кажучы ўжо пра выкарыстанне. Бо па вызначэнні ФС – гэта падсістэма АС, адказная за эфектыўнае кіраванне рэсурсам "дыскавая прастора", чаго ў выпадку c Btrfs мы не назіраем. Ну, уявіце, што вы прыйшлі ў краму купіць гадзіннік, каб не спазняцца на працу, а там замест гадзін вам упарылі электрагрыль з таймерам на 30 хвілін максімум. Дык вось – з Btrfs сітуацыя яшчэ горшая.
Праглядаючы лісты рассылак, я часта сутыкаюся са сцвярджэннем, што эфектыўна кіраваць дыскавай прасторай ужо не актуальна з прычыны таннасці назапашвальнікаў. Гэта поўнае трызненне. Без эфектыўнага мэнэджара дыскавай прасторы АС стане ўразлівай і непрыдатнай да выкарыстання. Незалежна ад таго, які ёмістасці дыскі стаяць на вашай машыне.
Хацелася б папрасіць пракаментаваць спыненне падтрымкі Btrfs у RHEL.
Тут асабліва няма чаго каментаваць, усё вельмі ясна. Яна ж была ў іх "technology preview". Вось, і не прайшла гэта самае "preview". Не вісець жа вечна гэтаму ярлыку! А запусціць недасканалы by-design прадукт з поўнай падтрымкай яны не могуць. RHEL - гэта энтэрпрайз, гэта значыць прапісаныя таварна-грашовыя адносіны. Red Hat не можа здзекавацца з карыстальнікаў, як гэта адбываецца ў лісце рассылання Btrfs. Проста ўявіце сітуацыю: кліент, які заплаціў свае крэўныя за дыск і яшчэ вам за падтрымку, хоча зразумець, куды падзелася яго дыскавая прастора, пасля таго, як ён нічога не запісаў. Што вы яму на гэта адкажаце?
Далей. У лік кліентаў Red Hat уваходзяць вядомыя буйныя слоікі, біржы. Уявіце, што будзе, калі яны падвергнуцца DoS-нападам, заснаваным на згаданай уразлівасці ў Btrfs. Як вы думаеце, хто за гэта адкажа? Тым, хто сабраўся ткнуць пальцам у радок ліцэнзіі GPL, дзе напісана, што аўтар ні завошта не адказвае, адразу скажу: "схавайце яе далей!" Адкажа Red Hat, прычым так, што мала не здасца! Але я ведаю, што Red Hat-у такога роду праблемы не пагражаюць, улічваючы іх асабліва моцную каманду QA-інжынераў, з якімі мне давялося шчыльна папрацаваць у свой час.
Чаму некаторыя кампаніі працягваюць падтрымліваць Btrfs у сваіх энтерпрайз-прадуктах?
Заўважце, што прыстаўка «энтэрпрайз» у назове прадукта мала аб чым кажа. Энтэрпрайз - гэта мера адказнасці, закладзеная ў дагаворныя адносіны з кліентам. Я ведаю толькі адзін энтэрпрайз, заснаваны на GNU/Linux – гэта RHEL. Усё астатняе, на мой погляд, толькі выдаецца за энтэрпрайз, але такім не з'яўляецца. І, нарэшце, калі на штосьці ёсць попыт, то заўсёды будзе і прапанова (у нашым выпадку гэта згаданая "падтрымка"). Попыт жа бывае абсалютна на ўсё, у т.л. і на непрыдатны да выкарыстання софт. Як ён фарміруецца такі попыт, і хто яго падсілкоўвае - гэта ўжо іншая тэма.
Так што, я б не стаў рабіць нейкія высновы пасля таго, як Facebook па чутках разгарнуў Btrfs на сваіх серверах. Больш за тое, адрасы тых сервераў я б парэкамендаваў старанна захоўваць у таямніцы па вышэйзгаданых прычынах.
Чаму ў апошні час вельмі шмат намаганняў прыкладзена да вылізвання кода XFS? Бо першапачаткова гэта іншая ФС, ды і ext4 даўно стабільная і мае пераемнасць ад папярэдніх такіх жа стабільных версій. Якая цікавасць у Red Hat'а да XFS? Ці ёсць сэнс актыўна распрацоўваць дзве падобныя па прызначэнні ФС – ext4 і XFS?
Ужо не памятаю, чым гэта матывавалася. Магчыма, што ініцыятыва ішла ад кліентаў Red Hat. Я памятаю, што праводзіліся даследаванні такога роду: на некаторых файлавых сістэмах з апстрыму стваралася гіганцкая колькасць аб'ектаў на хай-енд назапашвальніках новага пакалення. Па выніках XFS павяла сябе лепш ext4. Вось яе і сталі прасоўваць як найболей перспектыўную. У любым выпадку, я б не шукаў тут чагосьці сенсацыйнага.
Па мне, так змянілі шыла на мыла. Распрацоўваць ext4 і XFS няма сэнсу. Як паралельна, так і любую з іх на выбар. З гэтага нічога добрага не атрымаецца. Хоць, у прыродзе часта сустракаюцца сітуацыі, калі патэнцый для росту шмат, а аб'ёму куды расці няма. У гэтым выпадку ўзнікаюць розныя мудрагелістыя наватворы, на якія ўсё паказваюць пальцам («О, глядзі, чаго толькі ў гэтым жыцці не ўбачыш!»).
Ці лічыш ты пытанне аб layer violation вычарпаным (у негатыўным сэнсе) са з'яўленнем функцый шыфравання ў ext4, F2FS (не кажучы ўжо пра RAID у Btrfs)?
Наогул, увядзенне якіх-небудзь узроўняў і прыняцце рашэння аб іх непарушэнні - гэта звычайна пытанне палітыкі, і я не бяруся тут штосьці каментаваць. Аб'ектыўныя ж аспекты парушэння узроўняў мала каму цікавыя, але мы можам разгледзець некаторыя з іх на прыкладзе парушэння "зверху", а менавіта, рэалізацыю ў ФС функцыянальнасці, ужо наяўнай на block layer. Такое "парушэнне" апраўдана ўсяго толькі за рэдкім выключэннем. Для кожнага такога выпадку вы спачатку павінны даказаць дзве рэчы: што гэта сапраўды трэба, і што дызайну сістэмы пры гэтым не будзе нанесены ўрон.
Скажам, люстраванне, якое традыцыйна з'яўлялася заняткам для block layer, мае сэнс рэалізаваць на ўзроўні файлавай сістэмы. Па розных прычынах. Напрыклад, на дыскавых назапашвальніках мае месца "ціхая" псута дадзеных (bit rot). Гэта калі прылада спраўна працуе, але дадзеныя блока нечакана пашкоджваюцца пад уздзеяннем цвёрдага гама-кванта, выпушчанага далёкім квазарам і да т.п. Горш за ўсё, калі гэтым блокам аказаўся сістэмны блок ФС (суперблок, bitmap-блок, вузел дрэва-сховішча і г.д), бо гэта абавязкова прывядзе да kernel panic.
Заўважце, што люстэркі, якi прапануе block layer (т.зв. RAID 1) ад гэтай праблемы не выратуюць. Ну, сапраўды: нехта ж павінен правяраць кантрольныя сумы і счытваць рэпліку ў выпадку няўдачы? Акрамя таго, мае сэнс люстэркаваць не тупа ўсё запар, а толькі метададзеныя. Некаторыя важныя дадзеныя (напрыклад, выкананыя файлы крытычных прыкладанняў) можна захоўваць на правах мета-дадзеных. У гэтым выпадку яны атрымліваюць такія ж гарантыі бяспекі. Абарону ж астатніх дадзеных мае сэнс даручыць іншым падсістэмам (магчыма, нават карыстацкім прыкладанням) – мы падалі для гэтага ўсе неабходныя ўмовы.
Такія "эканомныя" люстэркі суцэль маюць права на існаванне і эфектыўна іх арганізаваць можна толькі на ўзроўні файлавай сістэмы. У астатнім жа layering violation – гэта захламленне падсістэмы дубляваным кодам дзеля нейкіх мікраскапічных выгод. Яркі таму прыклад – гэта рэалізацыя RAID-5 сродкамі ФС. Такія рашэнні (уласныя RAID / LVM у файлавай сістэме) забівае апошнюю ў архітэктурным плане. Тут яшчэ трэба адзначыць, што layering violation "пастаўлена на паток" рознага роду маркетынгавымі ашуканцамі. За адсутнасцю якіх-небудзь ідэй, у падсістэмы дадаецца функцыянальнасць даўно ўжо рэалізаваная на суседніх узроўнях, гэта выдаецца за новую надзвычай карысную фічу і актыўна прапіхваецца.
Reiser4 жа абвінавацілі ў парушэнні ўзроўняў знізу . Зыходзячы з таго, што файлавая сістэма не маналітная, як усе астатнія, а модульная, было зроблена нічым не абгрунтаваная здагадка, што яна займаецца тым, чым павінен займацца ўзровень вышэй (VFS).
Ці можна казаць аб смерці ReiserFS v3.6 і, напрыклад, JFS? Апошнім часам ім у ядры амаль не надаецца ўвагі. Яны маральна састарэлі?
Тут трэба вызначыць, што значыць смерць праграмнага прадукта. З аднаго боку, яны з поспехам выкарыстоўваюцца (іх для гэтага і стваралі, у выніку) - значыць жывуць. З іншага боку, не скажу за JFS (мала ведаю), а вось ReiserFS (v3) вельмі цяжка прыстасаваць да новых тэндэнцый (праверана на практыцы). Значыць, распрацоўшчыкі ў далейшым будуць надаваць увагу не ёй, а тым, якія лягчэй прыстасаваць. З гэтага боку атрымліваецца, што, нажаль, мёртвая ў архітэктурным плане. Паняццем «маральна састарэлы» я б наогул не маніпуляваў. Яно добра дастасавальна, напрыклад, да гардэроба, але ніяк не да праграмных прадуктаў. Ёсць паняцце саступаць і пераўзыходзіць у чым-небудзь. Цалкам сапраўды магу сказаць, што ReserFS v3 зараз ва ўсім саступае Reiser4, але на некаторых тыпах працоўнай нагрузкі пераўзыходзіць усе астатнія ФС з апстрыму.
Ці вядома табе аб распрацоўцы ФС Tux3 і HAMMER/HAMMER2 (ФС для DragonFly BSD)?
Так, вядома. У Tux3 мяне калісьці зацікавіла тэхналогія іх здымкаў (т.зв. "версійныя паказальнікі"), але ў Reiser4 мы, хутчэй за ўсё, пойдзем іншым шляхам. Я даўно думаю аб падтрымцы здымкаў (snapshots) і яшчэ не вызначыўся з тым, як іх рэалізаваць для простых Reiser4 тамоў. Справа ў тым, што навамодная тэхніка «гультаяватых» лічыльнікаў спасылак, прапанаваная Охадам Радехам, працуе толькі для B-дрэў. У нас іх няма. Для тых структур дадзеных, якія выкарыстоўваюцца ў Reiesr4, «гультаяватыя» лічыльнікі не вызначаны – для іх увядзення неабходна вырашыць пэўныя алгарытмічныя праблемы, за што пакуль ніхто не браўся.
Па HAMMERу: чытаў артыкул ад стваральніка. Не зацікавіла. Ізноў жа, B-дрэвы. Гэтая структура дадзеных безнадзейна састарэла. Мы адмовіліся ад яе яшчэ ў мінулым стагоддзі.
Як ты ацэньваеш нарастальную запатрабаванасць у сеткавых кластарных ФС па тыпе CephFS/GlusterFS/etc? Ці азначае гэтая запатрабаванасць зрух прыярытэтаў распрацоўшчыкаў у бок сеткавых ФС і недастатковасць увагі да лакальных ФС?
Так, такі зрух прыярытэтаў адбыўся. Распрацоўка лакальных ФС стагнавала. Нажаль, зрабіць нешта істотнае для лакальных тамоў зараз даволі складана і далёка не ўсім пад сілу. Укладвацца ў іх распрацоўку ніхто не жадае. Гэта прыкладна гэтак жа, як папрасіць камерцыйную структуру вылучыць грошы на матэматычныя даследаванні - вас без этнузіязму спытаюць, а як на новай тэарэме можна будзе зарабіць. Зараз лакальная ФС - гэта нешта, што магічна з'яўляецца "са скрынкі" і "заўсёды павінна працаваць", а калі не працуе, то выклікае бязадраснае бурчанне накшталт: "так, што яны там сабе думаюць!".
Адгэтуль недахоп увагі да лакальных ФС, хоць працы ў той вобласці яшчэ безліч. І так, усё павярнуліся да размеркаваных сховішчаў, якія будуюцца на базе ўжо існуючых лакальных ФС. Гэта зараз вельмі модна. Словазлучэнне «Big Data» у шматлікіх выклікае выкід адрэналіну, асацыюючыся з канферэнцыямі, воркшопамі, вялікімі заробкамі і да т.п.
Наколькі разумным у прынцыпе выглядае падыход, пры якім сеткавая ФС рэалізуецца ў прасторы ядра, а не ў прасторы карыстача?
Вельмі разумны падыход, які да гэтага часу нідзе не быў рэалізаваны. Наогул, пытанне аб тым, у якой прасторы трэба рэалізоўваць сеткавую ФС – гэта "палка аб двух канцах". Ну, давайце разгледзім на прыкладзе. Кліент запісаў дадзеныя на выдаленай машыне. Яны ўпалі ў яе page cache у выглядзе брудных старонак. Гэта праца для "тонкага шлюза" сеткавай ФС у прасторы ядра. Далей аперацыйная сістэма рана ці позна папросіць запісаць тыя старонкі на дыск для іх вызвалення. Тады ў справу ўключаецца IO-forwarding (адпраўляючы) моду сеткавай ФС. Ён вызначае на якую серверную машыну (server node) гэтыя старонкі патрапяць.
Потым эстафету прымае сеткавы стэк (а ён, як мы ведаем, рэалізаваны ў прасторы ядра). Далей, server node прымае той пакет з дадзенымі або метададзенымі і дае ўказанне backend storage - модулю (г.зн. лакальнай ФС, якая працуе ў прасторы ядра) запісаць усю гэту гаспадарку. Такім чынам, мы звялі пытанне да таго, дзе павінны працаваць які адпраўляе і які прымае модулі. Калі які-небудзь з тых модуляў працуюць у прасторы карыстача, тое гэта немінуча прывядзе да пераключэння кантэкстаў (з-за неабходнасці карыстання сэрвісамі ядра). Лік такіх пераключэнняў залежыць ад дэталяў рэалізацыі.
Калі такіх пераключэнняў шмат, то будзе падаць прапускная здольнасць сховішчы (прадукцыйнасць уводу-вываду). Калі ваш backend storage складзены з павольных кружэлак, то значнага падзення вы не заўважыце. Але калі ў вас дыскі хуткія (SSD, NVRAM і г.д), то пераключэнне кантэкстаў ужо становіцца "бутэлькавым рыльцам" і, зэканоміўшы на пераключэнні кантэкстаў, прадукцыйнасць можна павялічыць у разы. Стандартны шлях такой эканоміі складаецца ў пераносе модуляў у прастору ядра. Да прыкладу, мы высветлілі, што перанос 9p-сервера з QEMU у ядро на хост-машыне прыводзіць да трохразовага прыросту прадукцыйнасці VirtFS.
Гэта, вядома, не сеткавая ФС, але іста рэчаў суцэль адлюстроўвае. Адваротны бок такой аптымізацыі - гэта праблемы з пераноснасцю. Для кагосьці апошняя можа аказацца крытычнай. Напрыклад, GlusterFS наогул не мае модуляў у складзе ядра. Дзякуючы гэтаму яна зараз працуе на шматлікіх платформах, у тым ліку і на NetBSD.
Якія канцэпцыі лакальныя ФС маглі б запазычыць у сеткавых і наадварот?
Цяпер сеткавыя ФС, як правіла, ёсць надбудовы над лакальнымі ФС, таму я не зусім разумею, як можна ў апошніх нешта запазычыць. Ну, сапраўды, разгледзім кампанію з 4 супрацоўнікаў, у якой кожны займаецца сваёй справай: адзін размяркоўвае, іншы адпраўляе, трэці атрымлівае, чацвёрты захоўвае. І пытанне, а што ж кампанія можа запазычыць ад яе супрацоўніка, які захоўвае, гучыць неяк некарэктна (тое, што можна было ад яго запазычыць яна ўжо даўно мае).
А вось лакальным ФС ёсць чаму павучыцца ў сеткавых. Па-першае, у іх варта павучыцца агрэгаваць лагічныя тамы на высокім узроўні. Цяпер т.зв. "перадавыя" лакальныя ФС агрэгуюць лагічныя тамы выключна пры дапамозе тэхналогіі "віртуальных девайсов", запазычанай з LVM (той самы заразны layering violation, які спачатку быў рэалізаваны ў ZFS). Інакш кажучы, адбываецца трансляцыя віртуальных адрасоў (нумароў блокаў) у рэальныя і зваротна на нізкім узроўні (г.зн. пасля таго, як файлавая сістэма выдала запыт уводу-высновы).
Заўважце, што даданне і выдаленне прылад у лагічныя тамы (не люстэркі), скампанаваныя на block layer вядзе да праблем, пра якія пастаўшчыкі падобных "фіч" сціпла замоўчваюць. Я кажу, аб фрагментацыі на рэальных прыладах, якая можа дасягаць жахлівых значэнняў, у той час, як на віртуальнай прыладзе ў вас усё выдатна. Аднак віртуальныя прылады мала каго цікавяць: усім цікава, што ў вас адбываецца на рэальных прыладах. Але ZFS-падобныя ФС (таксама як і любыя ФС у звязках з LVM) працуюць толькі з віртуальнымі дыскавымі прыладамі (вылучаюць віртуальныя дыскавыя адрасы з ліку вольных, дэфрагментуюць гэтыя віртуальныя прылады і г.д.). А што адбываецца на рэальных прыладах яны нават паняцця не маюць!
Зараз прадстаўце, што на віртуальнай прыладзе ў вас фрагментацыя роўная нулю (гэта значыць, у вас тамака жыве ўсяго адзін гіганцкі экстэнт), вы дадаеце кружэлку ў ваш лагічны том, а затым выдаляеце іншую выпадковую кружэлку з вашага лагічнага тома з наступным перабалансаваннем. Дык вось шмат разоў. Няцяжка сцяміць, што на віртуальнай прыладзе ў вас па-ранейшаму будзе жыць той самы адзіны экстэнт, але вось на рэальных прыладах вы нічога добрага ўжо не ўбачыце.
Горш за ўсё тое, што вы нават не ў стане выправіць гэтую сітуацыю! Адзінае, што тут можна зрабіць - гэта папрасіць файлавую сістэму дэфрагментаваць віртуальную прыладу. Але яна вам скажа, што ў вас там усё выдатна - ёсць адзін толькі экстэнт, фрагментацыя роўная нулю, а лепшага і быць не можа! Такім чынам, лагічныя тамы, кампанаваныя на блокавым узроўні не прызначаны для шматразовага дадання/выдаленні прылад. Па-добраму, трэба толькі адзін раз кампанаваць лагічны том на блокавым узроўні, аддаць яго файлавай сістэме, і потым нічога ўжо больш з ім не рабіць.
Акрамя таго, звязак незалежных падсістэм ФС+LVM ніяк не дазваляе ўлічваць розную прыроду назапашвальнікаў, з якіх агрэгуюцца лагічныя тамы. Сапраўды, выкажам здагадку, скампанавалі вы лагічны том з НЖМД і цвёрдацельных прылад. Але тады першыя запатрабуюць дэфрагментацыі, а другія - не. Для другіх трэба выдаваць discard-запыты, а для першых - не, і да т.п. Аднак ва ўказаным звязку такую выбіральнасць праявіць дастаткова складана.
Заўважце, што пасля стварэння ў файлавай сістэме свайго ўласнага LVM, сітуацыя моцна лепшай не становіцца. Больш за тое, гэтым вы фактычна ставіце крыж на пэрспэктыве калі-небудзь яе палепшыць у будучыні. Гэта вельмі дрэнна. На адной і той жа машыне могуць жыць назапашвальнікі рознага тыпу. І калі не файлавая сістэма будзе іх адрозніваць, то хто тады?
Яшчэ адна праблема падсцерагае т.зв. "Write-Anywhere" файлавыя сістэмы (сюды ж уваходзіць і Reiser4, калі падчас мантавання вы задалі адпаведную транзакцыйную мадэль). Такія файлавыя сістэмы павінны прад'явіць беспрэцэдэнтныя па сваёй моцы сродкі дэфрагментацыі. А нізкаўзроўневы менеджэр тамоў тут не дапамагае, а толькі замінае. Справа ў тым, што з такім мэнэджэрам ваша ФС будзе захоўваць карту вольных блокаў толькі аднаго девайса - віртуальнага. Адпаведна, дэфрагментаваць вы зможаце толькі віртуальны дэвайс. Гэта значыць, што дэфрагментатар ваш будзе доўга-доўга араць на велізарнай адзінай прасторы віртуальных адрасоў.
І калі ў вас шмат карыстальнікаў, якія робяць выпадковыя перазапісы, то карысны эфект ад такога дэфрагментатара звядзецца да нуля. Сістэма ваша немінуча пачне тармазіць, і вам застанецца толькі скласці рукі перад несуцяшальным дыягназам broken design . Некалькі дэфрагментатараў, якія працуюць на адной і той жа прасторы адрасоў будуць толькі замінаць адзін аднаму. Зусім іншая справа, калі для кожнай рэальнай прылады вы падтрымліваеце сваю карту вольных блокаў. Гэта дазволіць эфектыўна распаралеліць працэс дэфрагментацыі.
Але зрабіць гэта можна, толькі валодаючы высокаўзроўневым мэнэджэрам лагічных тамоў. Лакальных ФС з такімі мэнэджэрамі раней не існавала (прынамсі, я пра іх не ведаю). Такімі мэнэджэрамі валодалі толькі сеткавыя ФС (напрыклад GlusterFS). Іншы вельмі важны прыклад – утыліта праверкі цэласнасці тома (fsck). Калі для кожнага подтома ў вас захоўваецца свая незалежная карта вольных блокаў, то працэдуру праверкі лагічнага тома можна эфектыўна распаралеліць. Інакш кажучы, лагічныя тамы з высокаўзроўневымі мэнэджэрамі лепш маштабуюцца.
Акрамя таго, з нізкаўзроўневымі мэнэджэрамі тамоў вы не зможаце арганізаваць паўнавартасныя здымкі (snapshots). З LVM і ў ZFS-падобных ФС вы можаце рабіць толькі лакальныя здымкі, але ніяк не глабальныя. Лакальныя здымкі дазваляюць маментальна адкочваць толькі рэгулярныя файлавыя аперацыі. A аперацыі з лагічнымі тамамі (даданне / выдаленне прылад) вам ніхто там не адкоціць. Давайце разгледзім гэта на прыкладзе. У некаторы момант часу, калі ў вас маецца лагічны том з двух прылад А і Ў, утрымоўвальны 100 файлаў, вы робіце здымак S сістэмы і затым ствараеце яшчэ адну сотню файлаў.
Пасля гэтага вы дадаеце да вашага таго прылада З, і нарэшце адкочваеце вашу сістэму да здымка S. Пытанне: колькі файлаў і прылад утрымоўвае ваш лагічны том пасля адкату да S? Файлаў, як вы ўжо здагадаліся, будзе 100, але вось прылад будзе 3 – гэта тыя ж прылады A, B і C, хоць, на момант стварэння здымка ў сістэме было ўсяго дзве прылады (A і B). Аперацыя дадання прылады C не адкацілася, і калі вы зараз выдаліце прыладу C з кампутара, тое гэта закаррапціць вашы дадзеныя, так што перад выдаленнем вам вам трэба будзе спачатку правесці дарагую аперацыю выдалення прылады з лагічнага тома з перабалансаваннем, якая раскідае ўсе дадзеныя з прылады C на прылады A і B. А вось калі б ваша ФС падтрымлівала глабальныя здымкі, такая перабалансіроўка б не запатрабавалася, і пасля маментальнага адкату да S вы бы маглі смела выдаліць прыладу C з кампутара.
Такім чынам, глабальныя здымкі добрыя тым, што яны дазваляюць пазбегнуць дарагога выдалення (даданні) прылады з лагічнага тома (у лагічны том) c вялікай колькасцю дадзеных (зразумела, калі вы не забыліся "сфатаграфаваць" сваю сістэму ў патрэбны момант). Нагадаю, што стварэнне здымкаў і адкат файлавай сістэмы да гэтых - маментальныя аперацыі. Можа ўзнікнуць пытанне: а як наогул такое магчыма - маментальна адкаціць аперацыю з лагічным томам, якая заняла ў вас тры дні? А вось магчыма! Пры ўмове, што ваша ФС правільна спраектавана. Ідэя такіх "3D-снапшотаў" у мяне ўзнікла тры гады таму, а ў мінулым годзе я запатэнтаваў гэтую методыку.
Наступнае, чаму варта павучыцца лакальным ФС у сеткавых - гэта захоўваць метададзеныя на асобных прыладах сапраўды гэтак жа, як сеткавыя ФС захоўваюць іх на асобных машынах (так званыя метадата-серверы). Ёсць прыкладанні, якія працуюць у асноўным з метададзенымі, і гэтыя прыкладанні можна значна паскорыць, размясціўшы метададзеныя на дарагіх высокапрадукцыйных назапашвальніках. Са звязкам ФС+LVM выявіць такую выбіральнасць вам не атрымаецца: LVM не ведае, што тамака на блоку, які вы яму перадалі (дадзеныя тамака ці метададзеныя).
Ад рэалізацыі ў ФС уласнага нізкаўзроўневага LVM вялікага выйгрышу ў параўнанні са звязкам ФС+LVM вы не атрымаеце, а вось што ў вас атрымаецца вельмі добрае — дык гэта захламіць ФС так, што потым стане немагчыма працаваць з яе кодам. ZFS і Btrfs, якія паспяшаліся з віртуальнымі аксэсуарамі, – гэта ўсё наглядныя прыклады таго, як layering violation забівае сістэму ў архітэктурным плане. Такім чынам, да чаго я ўсё гэта? Ды да таго, што не трэба гарадзіць у файлавай сістэме свой уласны нізкаўзроўневы LVM. Замест гэтага трэба агрэгаваць прылады ў лагічныя тамы на высокім узроўні, як гэта робяць некаторыя сеткавыя ФС з рознымі машынамі (storage nodes). Праўда, робяць яны гэта агідна з прычыны прымянення дрэнных алгарытмаў.
Прыклады зусім жудасных алгарытмаў - гэта транслятар DHT у файлавай сістэме GlusterFS і так званы CRUSH map у файлавай сістэме Ceph. Ніводны з тых алгарытмаў, што я бачыў, не задаволіў мяне ў плане прастаты і добрай маштабаванасці. А таму прыйшлося ўспамінаць алгебру і вынаходзіць усё самому. У 2015 годзе, эксперыментуючы з расслаеннямі над хэш-функцыямі, я прыдумаў і запатэнтаваў тое, што мяне задавальняе. Цяпер магу сказаць, што спроба рэалізаваць усё гэта на практыцы аказалася паспяховай. Ніякіх праблем з маштабаванасцю ў новым падыходзе я не бачу.
Так, кожны потым запатрабуе ў памяці асобную структуру тыпу суперблока. Гэта вельмі страшна? Наогул, я не ведаю, хто збіраецца "кіпяціць акіян" і ствараць лагічныя тамы з сотняў тысяч і больш прылад на адной лакальнай машыне. Калі хто-небудзь мне гэта растлумачыць, буду вельмі ўдзячны. А пакуль што для мяне гэта маркетынгавы булшыт.
Як паўплывалі змены ў падсістэме блокавых прылад ядра (напрыклад, з'яўленне blk-mq) на патрабаванні да рэалізацыі ФС?
Ніяк не паўплывалі. Ужо не ведаю, што тамака павінна такога здарыцца на block layer, што прыйшлося бы праектаваць новую ФС. Інтэрфейс узаемадзеяння гэтых падсістэм вельмі бедны. З боку драйвераў на ФС уплываць павінна толькі з'яўленне назапашвальнікаў новага тыпу, да якіх будзе падладжвацца спачатку block layer, а потым ужо ФС (для reiser4 гэта будзе азначаць з'яўленне новых убудоў).
Ці азначае з'яўленне новых тыпаў носьбітаў (напрыклад, SMR, ці паўсюднае распаўсюджванне SSD) прынцыпова новыя выклікі для праектавання ФС?
Так. І гэта нармальныя стымулы для развіцця ФС. Выклікі могуць быць розныя і зусім нечаканыя. Да прыкладу, я чуў аб назапашвальніках, дзе хуткасць аперацыі ўводу-высновы моцна залежыць ад памеру кавалка дадзеных і яго зрушэння. У Лінуксе, дзе памер ФС-блока не можа перавышаць памер старонкі, такі назапашвальнік па змаўчанні не выявіць свае поўныя магчымасці. Аднак, калі ваша ФС правільна спраектавана, гэта значыць шанец шмат яшчэ чаго з яго "выціснуць".
Колькі людзей зараз працуе з кодам Reiser4 акрамя цябе?
Менш, чым хацелася б, але і вострага недахопу рэсурсаў я не адчуваю. Тэмпы развіцця Reiser4 мяне больш за ўладкоўваюць. "Гнаць коней" я не збіраюся - гэта не тая вобласць. Тут «цішэй едзеш - далей будзеш!» Сучасная ФС - гэта самая складаная падсістэма ядра, няправільныя рашэнні ў дызайне якой могуць перакрэсліць наступную шматгадовую працу людзей.
Прапаноўваючы валанцёрам нешта рэалізаваць, я заўсёды гарантую, што намаганні абавязкова прывядуць да карэктнага выніку, які можа быць запатрабаваны для сур'ёзных патрэб. Як вы разумееце, такіх гарантыяў не можа быць шмат і адразу. У той жа час я трываць не магу "дзеячаў", якія бессаромна піяраць "фічы" загадзя непрыдатнага для выкарыстання софту, падманваючы сотні карыстальнікаў і распрацоўшчыкаў, ды пры гэтым сядзяць і ўсміхаюцца на кернэл самітах.
Ці выказвала якая-небудзь кампанія гатоўнасць падтрымаць распрацоўку Reiser4?
Так, такія прапановы былі, у т.л. і ад буйнога вендара. Але для гэтага мне трэба было пераязджаць у іншую краіну. Нажаль, мне ўжо даўно не 30 гадоў, я не магу сарвацца і з'ехаць вось так вось па першым свісце.
Якіх функцый не хапае ў Reiser4 зараз?
Бракуе функцыі "расцяжэнні" (resize) для простых тамоў па аналогіі з той, што маецца ў ReiserFS(v3). Акрамя таго, не перашкодзілі б файлавыя аперацыі са сцягам DIRECT_IO. Далей, хацелася б умець сегрэгаваць том на «семантычныя падтомы», якія не маюць фіксаванага памеру, і якія можна мантаваць як самастойныя тамы. Гэтыя задачы добрыя для пачаткоўцаў, якія жадаюць паспрабаваць сябе ў "сапраўднай справе".
І, нарэшце, хацелася б мець сеткавыя лагічныя тамы з простай рэалізацыяй і адміністраваннем (сучасныя алгарытмы ўжо дазваляюць гэта зрабіць). А вось чаго ў Reiser4 сапраўды ніколі не будзе – дык гэта RAID-Z, скрабаў, кэшаў вольнай прасторы, 128-бітных зменных і іншага маркетынгавага глупства, якая ўзнікла на фоне дэфіцыту ідэй у распрацоўнікаў некаторых ФС.
Ці ўсё тое, што можа спатрэбіцца, можа быць рэалізавана плягінамі?
Калі казаць толькі ў тэрмінах інтэрфейсаў і плагінаў (модуляў), якія іх рэалізуюць, то не ўсё. Але калі ўвесці яшчэ і адносіны на гэтых інтэрфейсах, то апроч усяго іншага ў вас узнікнуць паняцці вышэйшых палімарфізмаў, якімі ўжо можна абыйсціся. Уявіце, што вы гіпатэтычна замарозілі аб'ектна-арыентаваную сістэму часу выканання, памянялі значэнне instruction pointer, каб ён паказваў на іншую ўбудову, які рэалізуе той жа інтэрфейс X, а потым размарозілі сістэму, так каб яна працягнула выкананне.
Калі пры гэтым канчатковы карыстач не заўважыць такой "падмены", то мы кажам, што сістэма валодае палімарфізмам нулявога парадку ў інтэрфейсе X (ці сістэма гетэрагенная ў інтэрфейсе X, што тое ж самае). Калі зараз у вас не проста набор інтэрфейсаў, а яшчэ маюцца і адносіны на іх (граф інтэрфейсаў), то можна ўвесці палімарфізмы і больш высокіх парадкаў, якія будуць характарызаваць гетэрагеннасць сістэмы ўжо ў "наваколлі" якога-небудзь інтэрфейсу. Такую класіфікацыю я некалі даўно ўвёў, але апублікаваць, на жаль, так і не атрымалася.
Дык вось, пры дапамозе плагінаў і такіх вось вышэйшых палімарфізмаў можна апісаць любую вядомую фічу, а таксама «прадказаць» тыя, якія ніколі нават не згадваліся. Строга даказаць гэта мне не ўдалося, але і контрпрыклада я таксама пакуль не ведаю. Наогул, пытанне гэтае нагадала мне «Эрлангенскую праграму» Фелікса Клейна. Ён у свой час спрабаваў прадставіць усю геаметрыю раздзелам алгебры (канкрэтна, тэорыі груп).
Зараз да галоўнага пытання як ідуць справы з прасоўваннем Reiser4 у асноўнае ядро? Ці былі публікацыі па архітэктуры гэтай ФС, пра якія ты казаў у мінулым інтэрв'ю? Наколькі ўвогуле з твайго пункту гледжання гэтае пытанне актуальнае?
Наогул, мы на працягу трох гадоў прасілі аб уключэнні ў асноўную галінку. Апошні каментар Рэйзера ў публічным трэдзе, дзе быў зрабіў запыт на ўключэнне так і застаўся без адказу. Так што ўсе далейшыя пытанні - не да нас. Я ж асабіста не разумею, навошта нам "улівацца" у пэўную аперацыйную сістэму. На Лінуксе святло клінам не сышоўся. Так што, ёсць асобны рэпазітар, у якім будуць некалькі галінак-партоў пад розныя АС. Каму трэба - можаце кланаваць адпаведны порт і рабіць з ім усё што заманецца (у рамках ліцэнзіі, зразумела). Ну, а калі гэта камусьці не патрэбна, дык гэта не мае праблемы. На гэтым пытанне аб "прасоўванні ў асноўнае ядро Лінукс" я прапаную лічыць вычарпаным.
Публікацыі па архітэктуры ФС актуальныя, але я пакуль што знаходзіў час толькі на свае новыя вынікі, якія лічу больш прыярытэтнымі. Яшчэ справа ў тым, што я матэматык, а ў матэматыцы любая публікацыя - гэта зводка тэарэм і іх доказаў. Публікаваць там штосьці без доказу - гэта прыкмета благога тону. Калі ж я строга дакажу або абвергну якое-небудзь сцвярджэнне па архітэктуры ФС, то атрымаюцца такія нагрувашчванні, праз якія будзе даволі складана прадзерціся. Каму гэта патрэбна? Мусіць, таму ўсё працягвае заставацца ў сваім старым выглядзе - зыходны код і каментары да яго.
Што істотна новага з'явілася ў Reiser4 за апошнія некалькі гадоў?
Матэрыялізавалася, нарэшце, доўгачаканая стабільнасць. Адной з апошніх здалася памылка, якая прыводзіла да «невыдаляльных» дырэкторый. Цяжкасць была ў тым, што яна выяўлялася толькі на фоне калізій хэшаў імёнаў і пры вызначаным размяшчэнні дырэктарных запісаў у вузле дрэва. Аднак, для прадакшэна я Reiser4 па-ранейшаму рэкамендаваць не магу: для гэтага трэба правесці пэўную працу пры актыўным узаемадзеянні з адміністратарамі прадакшн-сістэм.
Атрымалася, нарэшце, рэалізаваць сваю даўнюю задумку - розныя транзакцыйныя мадэлі. Да гэтага ў Reiser4 працавала толькі адна жестковкодированная мадэль Макдональда-Рэйзера. Гэта стварала праблемы ў дызайне. У прыватнасці, у такой транзакцыйнай мадэлі немагчымыя здымкі (snapshots) – іх будзе псаваць кампанента атама пад назвай "OVERWRITE SET". Цяпер Reiser4 падтрымлівае тры транзакцыйныя мадэлі. У адной з іх (Write-Anywhere) у атамную кампаненту OVERWRITE SET уваходзяць толькі сістэмныя старонкі (вобразы дыскавых бітавых карт і да т.п.), якія "фатаграфаванню" не падлягаюць (праблема курыцы і яйкі).
Так што здымкі зараз можна рэалізаваць у лепшым выглядзе. У іншай транзакцыйнай мадэлі ўсе мадыфікаваныя старонкі пападаюць толькі ў OVERWRITE SET (гэта значыць, гэта па ісце чыстае часопісаванне). Гэтая мадэль для тых, хто скардзіўся на хуткую фрагментацыю Reiser4 раздзелаў. Зараз у гэтай мадэлі ваша частка будзе фрагментавацца не хутчэй чым з ReiserFS (v3). Усе тры існуючыя мадэлі за некаторымі агаворкамі гарантуюць атамарнасць аперацый, аднак спатрэбіцца могуць таксама і мадэлі са стратай атамарнасці і з захаваннем толькі цэласнасці часткі. Такія мадэлі могуць апынуцца карыснымі для разнастайных прыкладанняў (базы дадзеных і да т.п.), якія ўжо ўзвалілі на сябе частку падобных функцый. Дадаць гэтыя мадэлі ў Reiser4 вельмі лёгка, але я гэтага не рабіў, бо мяне ніхто не прасіў, а асабіста мне гэта не патрэбна.
З'явіліся кантрольныя сумы метададзеных і нядаўна я дапоўніў іх "эканамічнымі" люстэркамі» (пакуль нестабільны матэрыял). У выпадку правалу праверкі кантрольнай сумы якога-небудзь блока Reiser4 неадкладна счытвае адпаведны блок з дэвайса-рэплікі. Заўважце, што ZFS і Btrfs так не могуць: не дазваляе дызайн. Там вы павінны запусціць спецыяльны фонавы сканавальны працэс пад назвай «скраб» і чакаць, калі ён дабярэцца да праблемнага блока. Такія мерапрыемствы праграмісты вобразна называюць "мыліцамі".
І, нарэшце, з'явіліся гетэрагенныя лагічныя тамы, якія прапануюць усё тое, чаго ZFS, Btrfs, block layer, а таксама звязкі FS+LVM у прынцыпе даць не могуць – гэта паралельнае маштабаванне, O(1)-алакатар дыскавых адрасоў, празрыстая міграцыяй дадзеных паміж падтомамі. Для апошняй таксама маецца карыстацкі інтэрфейс. Зараз найболей «гарачыя» дадзеныя вы без працы можаце перамясціць на самы высокапрадукцыйны назапашвальнік вашага тома.
Акрамя таго, маецца магчымасць экстрана скідаць на такі назапашвальнік любыя брудныя старонкі, і, тым самым, значна паскорыць прыкладанні, часта выклікалыя fsync(2). Адзначу, што функцыянальнасць block layer, званая bcache, зусім не дае такой свабоды дзеянняў. Новыя лагічныя тамы заснаваныя на маіх алгарытмах (ёсць адпаведныя патэнты). Софт ужо досыць стабільны, суцэль можна паспрабаваць, замераць прадукцыйнасць і да т.п. Адзіная нязручнасць - пакуль трэба ўручную абнаўляць канфігурацыю тома і дзесьці яе захоўваць.
Рэалізаваць свае задумкі мне ўдалося пакуль што адсоткаў на 10. Аднак, атрымалася тое, што я лічыў найболей цяжкім - гэта «здружыць» лагічныя тамы з флаш-працэдурай, якая выконвае ўсе адкладзеныя дзеянні ў reiser4. Гэта ўсё пакуль у эксперыментальнай галінцы "format41".
Ці праходзіць Reiser4 тэсты xfstests?
Прынамсі, у мяне прайшла, калі я рыхтаваў апошні рэліз.
Ці магчыма ў прынцыпе з дапамогай плагінаў зрабіць Reiser4 сеткавай (кластарнай) ФС?
Можна і нават трэба! Калі на аснове правільна спраектаванай лакальнай ФС стварыць сеткавую, то вынік будзе вельмі уражлівым! У сучасных сеткавых ФС мяне не ўладкоўвае наяўнасць узроўня backend storage, які рэалізуецца пры дапамозе любой лакальнай ФС. Існаванне гэтага ўзроўню зусім неапраўдана. Сеткавая ФС павінна нармальна ўзаемадзейнічаць з block layer, і не прасіць лакальную ФС стварыць яшчэ нейкія тамака службовыя файлы!
Наогул, дзяленне файлавых сістэм на лакальныя і сеткавыя - гэта ад злога. Яно ўзнікла ад недасканаласці алгарытмаў, якімі карысталіся трыццаць гадоў таму, і замест якіх да гэтага часу нічога не было прапанавана. Гэта ж з'яўляецца прычынай з'яўлення масы непатрэбных софтверных кампанет (розных сэрвісаў і г.д). Па-добраму, павінна быць толькі адна ФС у выглядзе модуля ядра і набору карыстацкіх утыліт, усталёўваных на кожнай машыне - вузле кластара. Гэтая ФС адначасова і лакальная і сеткавая. І нічога лішняга!
Калі з Reiser4 у Linux'е так нічога і не атрымаецца, жадалася бы прапанаваць ФС для FreeBSD (вынятка з мінулага інтэрв'ю: «…FreeBSD … мае акадэмічныя карані… А гэта азначае, што з вялікай дзеллю верагоднасці мы знойдзем з распрацоўнікамі агульную мову») ?
Такім чынам, як мы толькі што высветлілі, з Лінуксам у нас усё ўжо выдатна атрымалася: пад яго ёсць асобны які працуе порт Reiser4 у выглядзе майстар-бранча нашага рэпазітара. Пра FreeBSD я і не забыўся! Прапануйце! Гатовы шчыльна папрацаваць з тымі, хто добра ведае вантробы FreeBSD. Дарэчы: што мне вельмі падабаецца ў іх супольнасці — там рашэнні прымаюцца абнаўлянай радай незалежных экспертаў, не мелым нічога агульнага з губанадзіманнем адной нязменнай персоны.
Як ты ацэньваеш супольнасць карыстальнікаў Linux сёння? Ці стала яно больш "папсовым"?
Мне па родзе сваёй дзейнасці ацаніць такое дастаткова цяжка. Да мяне ў асноўным прыходзяць карыстачы з багрэпортамі і просьбамі паправіць падзел. Карыстальнікі як карыстальнікі. Хтосьці падкаваны больш, хтосьці менш. Да ўсіх стаўленне аднолькавае. Ну, а калі карыстач ігнаруе мае ўказанні, то тут ужо прабачце: ігнор будзе ўведзены і з майго боку.
Ці магчыма спрагназаваць развіццё файлавых сістэм на бліжэйшыя пяць-дзесяць гадоў? Якія, па-твойму, асноўныя выклікі могуць стаяць перад распрацоўшчыкамі ФС?
Так, зрабіць такі прагноз нескладана. У апстрыме даўно ўжо няма ніякага развіцця файлавых сістэм. Ствараецца толькі бачнасць такога. Распрацоўнікі лакальных ФС упёрліся ў праблемы злучаныя з няўдалым дызайнам. Тут трэба зрабіць агаворку. Т.зв "захоўванне", "вылізванне" і партаванне кода я за развіццё і распрацоўку не лічу. А непаразуменне пад назвай "Btrfs" да распрацовак не прылічаю па прычынах, якія я ўжо растлумачыў.
Кожны патч толькі пагаршае яе праблемы. Ну. і заўсёды знаходзяцца рознага кшталту “евангелісты”, у якіх “усё працуе”. У асноўным, гэта школьнікі і студэнты, якія прагульваюць лекцыі. Вы толькі ўявіце: у яго працуе, а ў прафесара няма. Гэта які ж выкід адрэналіну! Найбольшую ж шкоду з майго пункту гледжання прыносяць «умельцы», якія кінуліся з энтузіязмам «прышрубоўваць» цуда-фічы Btrfs да разнастайных праслойкам тыпу systemd, docker, і да т.п. - Гэта ўжо нагадвае метастазы.
Давайце зараз паспрабуем зрабіць прагноз на пяць-дзесяць гадоў. Што мы будзем рабіць у Reiser4 я сцісла ўжо пералічыў. Асноўным выклікам для распрацоўшчыкаў лакальных ФС з апстрыму стане (так, ужо стала) немагчымасць займацца прыстойнай справай за заробак. Без якіх-небудзь ідэй у вобласці захоўвання дадзеных яны будуць працягваць спрабаваць патчыць гэтыя няшчасныя VFS, XFS і ext4. Асабліва камічна на гэтым фоне выглядае сітуацыя з VFS, якая нагадвае азвярэлую мадэрнізацыю рэстарана ў якім кухароў няма, і не прадбачыцца.
Зараз код VFS без усякіх умоў залачвае адначасова некалькі старонак памяці і прапануе ніжэйлеглай ФС апераваць над імі. Гэта было ўведзена для падвышэння прадукцыйнасці Ext4 на аперацыях выдалення, але, як няцяжка зразумець, такі адначасовы лок зусім несумяшчальны з прасунутымі транзакцыйнымі мадэлямі. Гэта значыць, дадаць падтрымку нейкай разумнай ФС у ядры вы ўжо проста так не зможаце. Я не ведаю, як справа ідзе ў астатніх абласцях Linux, але што да файлавых сістэм, якое-небудзь развіццё тут ці наўрад сумяшчальна з палітыкай, якая праводзіцца Торвальдсам на справе (акадэмічныя праекты выганяюцца, а ашуканцам, не мелым паняцці, што такое B-дрэва , выдаюцца бясконцыя крэдыты даверу). Таму тут быў узяты курс на павольнае загніванне. Яго, вядома ж, з усіх сіл будуць спрабаваць выдаць за "развіццё".
Далей, «захавальнікі» файлавых сістэм, зразумеўшы, што на адным толькі «захоўванні» шмат не заробіш, будуць спрабаваць сябе ў больш прыбытковым бізнэсе. Гэта, як правіла, размеркаваныя файлавыя сістэмы і віртуалізацыя. Магчыма, кудысьці яшчэ будуць партаваць модную ZFS тамака, дзе яе яшчэ няма. Але яна, як і ўсе ФС з апстрыму, нагадвае навагоднюю ёлку: калі зверху яшчэ нешта з дробязі павесіць можна, то глыбей ужо не падлезеш. Я дапускаю, што пабудаваць сур'ёзную энтерпрайз-сістэму на базе ZFS можна, але паколькі мы цяпер абмяркоўваем будучыню, то мне застаецца са шкадаваннем канстатаваць, што ZFS у гэтым плане безнадзейная: сваімі віртуальнымі дэвайсамі хлопцы перакрылі сабе і будучым пакаленням кісло. ZFS - гэта ўчорашні дзень. А ext4 і XFS ужо нават не пазаўчарашні.
Асобна варта сказаць пра нашумелае паняцце "Linux file system of next generation". Гэта цалкам палітычны і маркетынгавы праект, створаны для магчымасці, так скажам, "слупіць будучыню файлавых сістэм" у Linux за пэўнымі персанажамі. Справа ў тым, што гэта раней Linux быў "just for fun". А зараз гэта перш за ўсё машына для зарабляння грошай. Яны робяцца на ўсім, на чым толькі можна. Да прыкладу, стварыць добры праграмны прадукт вельмі цяжка, але цямлівыя «распрацоўнікі» даўно ўжо сцямілі, што напружвацца-то зусім і не трэба: паспяхова прадаваць можна і неіснуючы софт, анансаваны і распіяраны на разнастайных публічных мерапрыемствах – галоўнае, каб у прэзентацыйных слайдах было пабольш "фіч".
Файлавыя сістэмы падыходзяць для гэтага як нельга лепш, бо на вынік можна смела выгандлёўваць лёт дзесяць. Ну, а калі хтосьці потым будзе наракаць на адсутнасць гэтага самага выніку, то ён жа ў файлавых сістэмах проста нічога не кеміць! Гэта нагадвае фінансавую піраміду: на вяршыні размяшчаюцца заварылі гэтую кашу авантурысты, і тыя нямногія, каму "пашанцавала": яны "знялі дывідэнды", г.зн. атрымалі грошы на распрацоўку, уладкаваліся мэнэджэрамі на высокааплатную працу, "засвяціліся" на канферэнцыях, і да т.п.
Далей ідуць тыя, каму «не пашанцавала»: яны будуць падлічваць страты, расхлёбваць наступствы разгортвання ў прадакшн непрыдатнага праграмнага прадукта», і г.д. Іх значна больш. Ну, і ў падставе піраміды – велізарная маса распрацоўшчыкаў, «пілуюць» нікчэмны код. Яны - у самым вялікім пройгрышы, бо марна патрачаны час не вернеш. Такія піраміды надзвычай выгадныя Торвальдсу і яго набліжаным. І чым гэтых пірамід больш - тым для іх лепш. Для падсілкоўвання такіх пірамід у ядро можа быць прынята ўсё што заўгодна. Зразумела, на публіцы яны сцвярджаюць адваротнае. Але я мяркую не па словах а па ўчынках.
Так што, "будучыня файлавых сістэм у Лінукс" - гэта чарговы моцна распіяренный, але мала прыдатны да выкарыстання софт. Пасля Btrfs з вялікай верагоднасцю месца такой "будучыні" зойме Bcachefs, якая ўяўляе сабой яшчэ адну спробу скрыжаваць Linux block layer з файлавай сістэмай (благі прыклад заразлівы). І што характэрна: тамака тыя ж праблемы, што і ў Btrfs. Я даўно гэта падазраваў, а потым неяк не ўтрымалася і зазірнуў у код - так і ёсць!
Аўтары Bcachefs і Btrfs, ствараючы свае ФС, актыўна карысталіся чужымі зыходнікамі, мала што ў іх разумеючы. Сітуацыя вельмі нагадвае дзіцячую гульню "сапсаваны тэлефон". І я прыкладна ўяўляю, як будзе адбывацца ўключэнне гэтага кода ў ядро. Уласна "граблі" ніхто не ўбачыць (на іх усе будуць наступаць потым). Пасля шматлікіх прыдзірак да стылю кода кода, абвінавачванні ў неіснуючых парушэннях, і інш. будзе рабіцца зняволенне аб "лаяльнасці" аўтара, аб тым, наколькі ён добра "ўзаемадзейнічае" з астатнімі распрацоўнікамі, і як паспяхова ўсё гэта потым можна будзе прадаваць карпарацыям.
Канчатковы ж вынік нікога не зацікавіць. Гадоў дваццаць таму, магчыма, бы і зацікавіў, але зараз пытанні ставяцца па-іншаму: ці ўдасца гэта раскруціць так, каб бліжэйшы дзесятак гадоў пэўныя людзі аказаліся працаўладкаваны. А задавацца пытаннем аб канчатковым выніку, нажаль, не прынята.
А наогул, я б настойліва не рэкамендаваў пачынаць вынаходзіць сваю файлавую сістэму "з нуля". Бо нават істотных фінансавых укладанняў будзе недастаткова, каб гадоў за дзесяць атрымаць нешта канкурэнтаздольнае. Зразумела, я кажу пра сур'ёзныя праекты, а не пра тыя, якія прызначаны для «праштурхвання» у ядро. Так што, больш эфектыўны спосаб заявіць пра сябе - гэта далучыцца да рэальных распрацовак, напрыклад да нас. Зрабіць гэта, зразумела, няпроста - але так справа ідзе з любым праектам высокага ўзроўню.
Спачатку трэба будзе самастойна адолець задачку, якую я прапаную. Пасля чаго, перакананы ў сур'ёзнасці вашых намераў, я пачну дапамагаць. Традыцыйна мы выкарыстоўваем толькі ўласныя напрацоўкі. Выключэнне складаюць алгарытмы кампрэсіі і некаторыя хэш-функцыі. Мы не адпраўляем распрацоўнікаў калясіць па канферэнцыях, а потым не сядзім і не камбінуем чужыя ідэі ("ану, чаго і атрымаецца"), як гэта прынята ў большасці стартапаў.
Усе алгарытмы мы распрацоўваем самі. У сапраўдны момант мяне цікавяць алгебраічныя і камбінаторныя аспекты навукі захоўвання дадзеных. У прыватнасці, канчатковыя палі, асімптотыка, доказ няроўнасцей. Для простых праграмістаў таксама знойдзецца праца, аднак павінен адразу папярэдзіць: усе прапановы "паглядзець на іншую ФС і зрабіць гэтак жа" адпраўляюцца ў ігнор. Туды ж пайдуць патчы, накіраваныя на больш цесную інтэграцыю з Linux па лініі VFS.
Такім чынам, у нас няма грабляў, а ёсць разуменне, куды трэба рухацца, і ёсць упэўненасць, што гэты кірунак правільны. Такое разуменне не прыйшло ў выглядзе манны нябеснай. Я нагадаю, што ззаду 29-летні досвед распрацовак, дзве файлавыя сістэмы напісаныя з нуля . І столькі ж утыліт аднаўлення звестак. А гэта вельмi шмат!
Крыніца: opennet.ru