Reiser4 файлдық жүйесін әзірлеуші Эдуард Шишкинмен екінші сұхбат жарияланды.
Алдымен оқырмандарға қайда және кім болып жұмыс істейтініңізді еске түсіріңіз.
Мен Huawei Technologies неміс зерттеу орталығында бас сақтау сәулетшісі болып жұмыс істеймін. Виртуализация бөлімінде деректерді сақтаудың әртүрлі аспектілерімен жұмыс істеймін. Менің жұмысым белгілі бір операциялық жүйеге бағытталмаған.
Сіз қазір негізгі ядро тармағына кірісіп жатырсыз ба?
Өте сирек және егер менің жұмыс берушім талап етсе ғана. Соңғы рет мен патчтарды шамамен үш жыл бұрын жібердім, бұл 9p протоколын (сонымен қатар VirtFS ретінде белгілі) хосттарда ортақ сақтауды арттыру үшін. Мұнда бір маңызды ескерту: мен Linux-пен ұзақ уақыт жұмыс істеген болсам да, мен ешқашан Linux фанаты болған емеспін. Мен оны ерекше ұнатпаймын, мен басқаларды жақсы көремін. Нақтырақ айтсам, кемшілікті байқасам, ең көбі бір рет көрсетемін. Біреудің соңынан еріп, кейін көндірудің қажеті жоқ.
Өткен жолы, он жыл бұрын сіз негізгі даму стиліне өте сын айтқаныңыз есімде. Сіздің (немесе мүмкін корпоративтік) көзқарасыңыздан бірдеңе өзгерді ме? Қауымдастық белсендірек болды ма? Олай болмаса, кім кінәлі деп ойлайсыз?
Мен ешқандай оң өзгерістерді байқамадым. Қауымдастықтың басты мәселесі - ғылымды саяси технологиялармен, жеке қарым-қатынастармен, көпшіліктің пікірімен, популизммен, «ішкі дауыстардың» кеңестерімен, шіріген ымыралармен – ғылымнан басқа кез келген нәрсемен алмастыру. Информатика, оны қалай қарасаңыз да, ең алдымен, дәл ғылым болып табылады. Ал егер біреу «2x2» үшін 4-тен өзгеше мағынаны жариялай бастаса, «Linux «жолмен» немесе кез келген басқа жағдайда, онда зияннан басқа ештеңе әкелмеуі екіталай.
Барлық келеңсіздіктер, ең алдымен, шешім қабылдаушылардың біліксіздігі мен білімсіздігінен туындайды. Егер басшы қабілетсіз болса, олар объективті, адекватты шешім қабылдауға қабілетсіз. Олар да мәдениетсіз болса, оларға дұрыс кеңес беретін сауатты маман таба алмай жүр. Олар «дұрыс айтатын сияқты» алаяқ адамды таңдайтын шығар. Біліксіз жалғыз басшылар әрқашан олардың айналасында сыбайлас жемқорлық шеңберін құрады. Тарих мұның ешбір ерекшелігін білмейді және қауымдастық мұның айқын мысалы болып табылады.
Btrfs дамуын қалай бағалайсыз? Бұл файлдық жүйе тістің шығуынан құтылды ма? Оны үйдегі файлдық жүйе ретінде немесе корпоративтік пайдалану үшін қалай орналастырасыз?
Мен одан құтылған жоқпын. 11 жыл бұрын айтқанымның бәрі бүгінде өзекті. Btrfs проблемаларының бірі, оны байыпты пайдалану үшін жарамсыз етеді - бос кеңістік мәселесі. Кез келген басқа файлдық жүйе бөлімде көп бос орынды көрсететін жағдайларда пайдаланушы жаңа диск үшін дүкенге жүгіруге мәжбүр болатынын айтпағанның өзінде. Бос орын жеткіліксіз болғандықтан логикалық көлемде операцияны аяқтамау ең жаман нәрсе емес. Ең сорақысы, артықшылықсыз пайдаланушы кез келген дискілік квоталарды айналып өтіп, әрқашан дерлік кез келген адамның бос орнын тез жоя алады.
Бұл былай көрінеді (ядро үшін тексерілген) Linux 5.12). Жаңадан орнатылған жүйеде циклде үй каталогында белгілі бір атаулары бар файлдарды жасайтын, оларға белгілі бір ығысуларда деректерді жазатын және содан кейін бұл файлдарды жоятын скрипт іске қосылады. Бұл скриптті іске қосқаннан кейін бір минуттан кейін ерекше ештеңе болмайды. Бес минуттан кейін бөлімдегі бос орын аздап артады. Екі-үш сағаттан кейін ол 50%-ға жетеді (бастапқы мәннен 15% дейін). Ал бес-алты сағаттан кейін скрипт «бөлімде бос орын жоқ» қатесімен істен шығады. Осыдан кейін сіз енді бөліміңізге тіпті 4K файл жаза алмайсыз.
Қызықты жағдай туындайды: сіз бөлімге ештеңе жазбадыңыз және барлық бос орын (шамамен 85%) жоғалып кетті. Мұндай шабуылға ұшыраған бөлімді талдау тек бір элементті (кілтпен жабдықталған нысан), өлшемі бірнеше байтты қамтитын көптеген ағаш түйіндерін көрсетеді. Басқаша айтқанда, бұрын дискілік кеңістіктің 15% алып тұрған мазмұн бүкіл бөлім бойынша біркелкі «жағынды» болды, сондықтан жаңа файл жазуға орын жоқ, өйткені оның кілті барлық бар файлдардан үлкенірек және бөлімде бос блоктар таусылды.
Оның үстіне, мұның бәрі негізгі Btrfs конфигурациясында орын алады (ешқандай суретсіз, ішкі томдарсыз және т.
Сіз басқа жоғары ағындық файлдық жүйелерді мұндай шабуылға ұшырата алмайсыз (кім сізге не айтса да). Мен мәселенің себебін түсіндірдім: Btrfs В-ағашының тұжырымдамасын толығымен бұрмалап, оны өздігінен немесе әдейі азғындауға бейім етеді. Атап айтқанда, белгілі бір жұмыс жүктемелерінде сіздің файлдық жүйеңіз жұмыс кезінде сыртқы көмексіз үздіксіз өздігінен «құлайды». Фондық процестердің барлық түрлері «қысым жасау» тек жеке жұмыс үстелдерінде күнді үнемдейтіні анық.
Ұжымдық бойынша серверлер Шабуылдаушы әрқашан олардан «алып» кете алады. Жүйе әкімшісі оны кім қорлағанын нақты анықтай алмайды. Btrfs-те бұл мәселені шешудің ең жылдам жолы - кәдімгі B-ағашының құрылымын қалпына келтіру, яғни диск форматын қайта жобалау және Btrfs кодының маңызды бөлігін қайта жазу. Бұл, егер әзірлеушілер тиісті алгоритмдер мен деректер құрылымдары бойынша түпнұсқа құжаттарды қатаң сақтаса және әдеттегідей (және қолдау көрсетілетіндей) «сынған телефонды» ойнатпаса, жөндеуді қоса алғанда, 8-10 жылды алады.Linux жол».
Сондай-ақ әзірлеушілер мұның бәрін анықтауға кететін уақытты қосуыңыз керек. Дәл осы жерде бәрі қиындай түседі. Қалай болғанда да, олар үшін оны анықтау үшін 10 жыл жеткіліксіз болды. Оған дейін ғажайыпқа сенбеңіз. Ол «біз білмедік» монтаждау опциясы немесе «жай ғана торттың бір бөлігі» патч түрінде болмайды. Әрбір осындай асығыс «түзету» үшін мен дегенерацияның жаңа сценарийін ұсынамын. B-ағаштар - менің сүйікті тақырыптарымның бірі, мен айта кету керек, бұл құрылымдар бостандыққа жол бермейді!
Btrfs қалай орналастырамын? Пайдалануды былай қойғанда, файлдық жүйе деп атауға болмайтын нәрсе ретінде. Анықтау бойынша, файлдық жүйе дискілік кеңістікті тиімді басқаруға жауап беретін ОЖ ішкі жүйесі болып табылады, бұл Btrfs қолданбасында емес. Дүкенге сағат сатып алу үшін барғаныңызды елестетіп көріңіз, сонда сіз жұмысқа кешігіп қалмассыз, оның орнына олар сізге ең көбі 30 минутқа созылатын таймері бар электр гриль сатады. Ал, Btrfs-пен жағдай одан да нашар.
Тарату тізімдерін шолу кезінде мен дискілер кеңістігін тиімді басқару енді өзекті емес деген пікірді жиі кездестіремін, өйткені дискілер өте арзан. Бұл мүлдем нонсенс. Дискілік кеңістікті тиімді басқарушы болмаса, операциялық жүйе құрылғыңыздағы дискілердің сыйымдылығына қарамастан осал және жарамсыз болады.
Мен RHEL-де Btrfs қолдауының аяқталуы туралы түсініктеме сұрағым келеді.
Бұл жерде түсініктеме беретін көп нәрсе жоқ; бәрі анық. Бұл олардың «технологиялық алдын ала қарауы» болды. Бұл «алдын ала қараудан» өткен жоқ. Олар бұл белгіні мәңгі сақтай алмайды! Және олар толық қолдаумен ақауы бар, қосымша дизайнды өнімді шығара алмайды. RHEL – кәсіпорын, яғни ол тауар-ақша қатынастарын анықтады. Red Hat Btrfs тарату тізіміндегідей пайдаланушыларды қорлай алмайды. Мынаны елестетіп көріңізші: дискі үшін, сондай-ақ сіздің қолдауыңыз үшін көп ақша төлеген тұтынушы ештеңе жазбаған соң дискілік кеңістіктің қайда кеткенін білгісі келеді. Сіз оларға не айтар едіңіз?
Келесі. Red Hat клиенттерінің арасында белгілі ірі банктер мен биржалар бар. Btrfs-те жоғарыда аталған осалдыққа негізделген DoS шабуылына ұшыраса, не болатынын елестетіп көріңіз. Кім жауапқа тартылады деп ойлайсыз? GPL лицензиясындағы автор жауапты емес деген жолды көрсеткісі келетіндерге мен бірден айтамын: «Жасырын!» Red Hat жауап береді және бұл өте таң қалдырады! Бірақ мен өз уақытымда тығыз жұмыс істеу мүмкіндігіне ие болған QA инженерлерінің күшті тобын ескере отырып, Red Hat-тың мұндай проблемаларға қауіп төндірмейтінін білемін.
Неліктен кейбір компаниялар Btrfs-ті кәсіпорын өнімдерінде қолдауды жалғастыруда?
Өнім атауындағы «enterprise» префиксінің көп мағына бермейтінін ескеріңіз. Enterprise – клиентпен жасалған келісімшарттық қарым-қатынасқа енгізілген жауапкершілік өлшемі. Мен GNU негізіндегі бір ғана кәсіпорынды білемін.Linux — бұл RHEL. Менің ойымша, қалғанының бәрі кәсіпорын ретінде жасырылған, бірақ олай емес. Соңында, егер бір нәрсеге сұраныс болса, әрқашан ұсыныс болады (біздің жағдайда, бұл жоғарыда аталған «қолдау»). Сұраныс барлық нәрсеге, соның ішінде пайдалануға жарамсыз бағдарламалық жасақтамаға да қатысты болуы мүмкін. Бұл сұраныс қалай қалыптасады және оны кім қамтамасыз етеді, бұл мүлдем басқа тақырып.
Сондықтан, Facebook өз серверлеріне Btrfs орнатқаны туралы қауесет тарағаннан кейін мен ешқандай қорытынды жасамас едім. Сонымен қатар, олардың мекенжайлары серверлер Жоғарыда айтылған себептерге байланысты оны мұқият құпия ұстауды ұсынамын.
Неліктен соңғы уақытта XFS кодын жылтыратуға көп күш жұмсалды? Өйткені, бұл бастапқыда үшінші тараптың файлдық жүйесі болды, ал ext4 ұзақ уақыт бойы тұрақты болды және бұрынғы, бірдей тұрақты нұсқалардың мұрасы бар. Red Hat компаниясының XFS-ке деген қызығушылығы қандай? Мақсаттары ұқсас екі файлдық жүйені - ext4 және XFS-ті белсенді түрде дамытудың мағынасы бар ма?
Оның астындағы мотивация есімде жоқ. Бастама Red Hat тұтынушыларынан шыққан болуы әбден мүмкін. Осындай зерттеулер болғаны есімде: кейбір жоғары ағындық файлдық жүйелерді пайдалану арқылы жаңа буынның жоғары деңгейлі дискілерінде көптеген нысандар жасалды. Нәтижелер XFS ext4-ке қарағанда жақсы жұмыс істейтінін көрсетті. Сондықтан олар оны ең перспективалы деп насихаттай бастады. Қалай болғанда да, мен бұл жерде сенсациялық ештеңе күтпес едім.
Менің ойымша, олар бір нәрсені екіншісіне айырбастады. Ext4 және XFS әзірлеудің мағынасы жоқ. Параллельді немесе кез келген опциямен. Одан жақсы ештеңе шықпайды. Табиғатта өсу әлеуеті көп, бірақ кеңейту мүмкіндігі жоқ жағдайлар жиі кездеседі. Бұл жағдайда әркім меңзейтін түрлі оғаш, ұсқынсыз жаңа өскіндер пайда болады («Ой, мына өмірде көретін нәрселердің бәрін қараңыз!»).
Қабатты бұзу мәселесі ext4, F2FS шифрлау мүмкіндіктерінің пайда болуымен шешілді деп ойлайсыз ба (Btrfs ішіндегі RAID туралы айтпағанда)?
Жалпы, кез келген қабаттарды енгізу және оларды бұзу туралы шешім әдетте саясат мәселесі болып табылады және мен оған түсініктеме бермеймін. Қабаттың бұзылуының объективті аспектілері ешкімді қызықтырмайды, бірақ біз олардың кейбірін жоғарыдан төмен бұзу мысалы арқылы қарастыра аламыз, атап айтқанда файлдық жүйедегі блоктық қабатта бұрыннан бар функционалдылықты жүзеге асыру. Мұндай «бұзушылық» сирек ерекше жағдайларда ғана ақталған. Әрбір осындай жағдай үшін алдымен екі нәрсені дәлелдеу керек: бұл шынымен қажет және ол жүйенің дизайнына зиян келтірмейді.
Мысалы, блоктық қабат үшін дәстүрлі түрде сақталған шағылыстыру файлдық жүйе деңгейінде жүзеге асырудың мағынасы бар. Мұның әртүрлі себептері бар. Мысалы, дискілер дыбыссыз деректердің бұзылуына (бит шіруіне) сезімтал. Бұл құрылғы дұрыс жұмыс істегенде орын алады, бірақ блоктағы деректер алыстағы квазар шығаратын қатты гамма-сәулемен күтпеген жерден зақымдалады, т.б. Бұл блок файлдық жүйе блогы (суперблок, нүктелік кескін блогы, сақтау ағашының түйіні және т.б.) болғанда, бұл сөзсіз дүрбелеңге әкеледі.
Блоктық қабат (RAID 1 деп аталатын) ұсынатын айналар бұл мәселені шешпейтінін ескеріңіз. Өйткені, біреу тексеру сомасын тексеріп, сәтсіздікке ұшыраған жағдайда көшірмені оқуы керек. Сонымен қатар, барлығын емес, тек метадеректерді көрсету мағынасы бар. Кейбір маңызды деректер (мысалы, маңызды қолданбалардың орындалатын файлдары) метадеректер ретінде сақталуы мүмкін. Бұл жағдайда олар бірдей қауіпсіздік кепілдіктерін алады. Басқа деректерді қорғауды басқа ішкі жүйелерге (мүмкін тіпті пайдаланушы қолданбаларына) беру мағынасы бар — біз бұл үшін барлық қажетті шарттарды жасадық.
Мұндай «үнемді» айналар толығымен орындалады және олар тек файлдық жүйе деңгейінде тиімді түрде жүзеге асырылуы мүмкін. Дегенмен, қабаттастыруды бұзу микроскопиялық пайда үшін қосалқы жүйені қайталанатын кодпен толтыру болып табылады. Ең жақсы мысал - файлдық жүйеде RAID-5 енгізу. Мұндай шешімдер (файлдық жүйедегі жергілікті RAID/LVM) файлдық жүйені архитектуралық түрде бұзады. Сондай-ақ, қабаттарды бұзуды әртүрлі маркетингтік алаяқтар «жаппай өндіргенін» атап өткен жөн. Түпнұсқа идеялардың жоқтығынан, көрші деңгейлерде іске асырылған функционалдылық ішкі жүйелерге қосылады, жаңа, өте пайдалы мүмкіндік ретінде ұсынылады және белсенді түрде алға жылжытылады.
Reiser4 «төмендегі» қабаттарды бұзды деп айыпталды. Файлдық жүйе басқалары сияқты монолитті емес, модульдік екенін ескере отырып, ол жоғарыдағы қабат (VFS) істеуі керек нәрсені орындайды деген негізсіз болжам жасалды.
ReiserFS v3.6 және, мысалы, JFS өлі деп айтуға болады ма? Соңғы уақытта олар ядроға аз көңіл бөледі. Олар ескірді ме?
Бұл жерде біз бағдарламалық өнім өлі болуы үшін нені білдіретінін анықтауымыз керек. Бір жағынан, олар сәтті қолданылуда (олар сол үшін жаратылған), сондықтан олар тірі. Екінші жағынан, мен JFS үшін сөйлей алмаймын (мен көп білмеймін), бірақ ReiserFS (v3) жаңа трендтерге бейімделу өте қиын (тәжірибеде дәлелденген). Бұл әзірлеушілер болашақта JFS емес, оңай бейімделетін шешімдерге назар аударатынын білдіреді. Бұл мағынада, өкінішке орай, сәулеттік тұрғыдан өлі. Мен «ескірген» терминін мүлдем қолданбас едім. Бұл, айталық, гардеробқа жақсы қолданылады, бірақ бағдарламалық жасақтамаға емес. Бір нәрседе төмен және жоғары болу деген ұғым бар. Мен ReiserFS v3 қазіргі уақытта барлық жағынан Reiser4-тен төмен екенін толық сенімділікпен айта аламын, бірақ жұмыс жүктемелерінің белгілі бір түрлері үшін ол барлық басқа жоғары ағындық файлдық жүйелерден асып түседі.
Сіз Tux3 және HAMMER/HAMMER2 (DragonFly BSD үшін FS) FS дамуы туралы білесіз бе?
Иә мен білемін. Tux3-те мені бір кездері олардың суретке түсіру технологиясы («нұсқалық көрсеткіштер» деп аталатын) қызықтырды, бірақ Reiser4-те біз басқа жолды таңдайтын шығармыз. Мен біраз уақыттан бері суретті қолдау туралы ойлап жүрмін және оны қарапайым Reiser4 томдары үшін қалай енгізу керектігін әлі шешкен жоқпын. Мәселе мынада, Охад Роде ұсынған жаңадан шыққан «жалқау» анықтамалық есептегіш техника тек B-ағаштары үшін жұмыс істейді. Бізде жоқ. Жалқау есептегіштер Reiser4-те пайдаланылған деректер құрылымдары үшін анықталмаған — оларды енгізу әлі ешкім шешпеген белгілі бір алгоритмдік есептерді шешуді талап етеді.
HAMMER туралы: Мен автордың мақаласын оқыдым. Бұл мені қызықтырмады. Тағы да, В-ағаштар. Бұл деректер құрылымы үмітсіз ескірген. Біз оны өткен ғасырда тастап кеткенбіз.
CephFS/GlusterFS/т.б. сияқты желілік кластерлік файлдық жүйелерге өсіп келе жатқан сұранысты қалай бағалайсыз? Бұл сұраныс әзірлеушілер басымдықтарының желілік файлдық жүйелерге ауысуын және жергілікті файлдық жүйелерге назар аудармауын көрсетеді ме?
Иә, басымдықтардың мұндай ауысуы орын алды. Жергілікті файлдық жүйелердің дамуы тоқтап қалды. Өкінішке орай, жергілікті томдар үшін маңызды нәрсені жасау қазір өте қиын және оны кез келген адам шеше алмайды. Олардың дамуына ешкім қаржы салғысы келмейді. Бұл шамамен коммерциялық ұйымнан математикалық зерттеулерге қаражат бөлуді сұраумен бірдей — олар сізден ешқандай этноссыз жаңа теоремадан қалай ақша табуға болатынын сұрайды. Енді жергілікті файлдық жүйе - бұл «қораптан тыс» және «әрқашан жұмыс істеуі керек» сиқырлы нәрсе, егер олай болмаса, ол «Олар кімді ойлап отыр?» деген сұраққа жауапсыз күңіренеді.
Демек, бұл салада әлі де көп жұмыс бар болса да, жергілікті файлдық жүйелерге назар аудармау. Иә, барлығы бар жергілікті файлдық жүйелердің үстіне салынған таратылған сақтау жүйелеріне жүгінді. Дәл қазір бәрі қызғаныш. «Үлкен деректер» тіркесі көптеген адамдар үшін адреналинді қоздырады, оны конференциялармен, семинарлармен, үлкен жалақымен және т.б. байланыстырады.
Желілік файлдық жүйе пайдаланушы кеңістігінде емес, ядро кеңістігінде жүзеге асырылатын көзқарас принципі қаншалықты орынды?
Әлі еш жерде жүзеге асырылмаған өте орынды тәсіл. Жалпы, желілік файлдық жүйені қай жерде іске асыру керектігі туралы мәселе екі жүзді қылыш болып табылады. Бір мысалды қарастырайық. Клиент деректерді қашықтағы құрылғыға жазады. Ол бет кэшінде лас беттер ретінде аяқталады. Бұл ядро кеңістігіндегі желілік файлдық жүйенің «жұқа шлюзінің» жұмысы. Ерте ме, кеш пе, операциялық жүйе бұл беттерді босату үшін дискіге жазуды сұрайды. Содан кейін желілік файлдық жүйенің IO бағытын өзгерту модулі іске қосылады. Бұл беттер қай серверлік машинада (сервер түйінінде) аяқталатынын анықтайды.
Содан кейін желілік стек (біз білетіндей, ядро кеңістігінде жүзеге асырылады) алады. Содан кейін сервер түйіні деректер немесе метадеректер бар пакетті алады және серверлік сақтау модуліне (яғни, ядро кеңістігінде жұмыс істейтін жергілікті файлдық жүйе) барлығын жазып алуды тапсырады. Сонымен, біз «жіберу» және «қабылдау» модульдері қай жерде жұмыс істеу керек деген сұрақты қысқарттық. Егер кез келген модуль пайдаланушы кеңістігінде жұмыс істесе, бұл сөзсіз контекстік қосқыштарға әкеледі (ядро қызметтерін пайдалану қажеттілігіне байланысты). Мұндай қосқыштардың саны іске асыру мәліметтеріне байланысты.
Осындай қосқыштар көп болса, сақтау өнімділігі (енгізу/шығару өнімділігі) төмендейді. Егер сіздің серверлік жадыңыз баяу дискілерден тұрса, айтарлықтай төмендеуді байқамайсыз. Бірақ егер сізде жылдам дискілер (SSD, NVRAM және т.б.) болса, контекстік қосқыштар тығырыққа тіреледі және контекстік қосқыштарды үнемдеу арқылы өнімділікті айтарлықтай арттыруға болады. Бұған қол жеткізудің жалпы жолы - модульдерді ядро кеңістігіне жылжыту. Мысалы, 9p серверін QEMU-дан хост ядросына жылжыту VirtFS өнімділігінің үш есе артуына әкелгенін анықтадық.
Бұл, әрине, желілік файлдық жүйе емес, бірақ мәселенің мәнін ашады. Бұл оңтайландырудың кемшілігі - тасымалдану мәселелері. Кейбіреулер үшін соңғысы маңызды болуы мүмкін. Мысалы, GlusterFS-те ядро модульдері мүлде жоқ. Осының арқасында ол қазір көптеген платформаларда, соның ішінде NetBSD-де жұмыс істейді.
Жергілікті ТҚЖ желілік ТЖ-дан қандай концепцияларды ала алады және керісінше?
Қазіргі уақытта желілік файлдық жүйелер әдетте жергілікті файлдық жүйелердің үстіне құрастырылған, сондықтан мен ешкімнің екіншісінен қалай ештеңе алуға болатынын түсінбеймін. Шынында да, әрқайсысы өз ісімен айналысатын төрт қызметкері бар компанияны қарастырыңыз: біреуі таратады, біреуі жібереді, біреуі алады және біреуі дүкендер жасайды. Ал компания дүкендермен айналысатын қызметкерден не қарыз ала алады деген сұрақ орынсыз болып көрінеді (олардың одан бұрыннан қарызға алатын нәрселері бар).
Жергілікті файлдық жүйелердің желілік файлдық жүйелерден үйренетін көп нәрсесі бар. Біріншіден, олар логикалық көлемдерді жоғары деңгейде біріктіруді үйренуі керек. Қазіргі уақытта «Жетілдірілген» деп аталатын жергілікті файлдық жүйелер логикалық көлемдерді тек LVM-ден алынған «виртуалды құрылғы» технологиясын пайдалана отырып біріктіреді (ZFS-те алғаш рет енгізілген бірдей жұқпалы қабаттық бұзушылық). Басқаша айтқанда, виртуалды мекенжайлар (блок нөмірлері) нақты мекенжайларға және кері төмен деңгейде (яғни файлдық жүйе енгізу/шығару сұрауын шығарғаннан кейін) аударылады.
Блоктық қабатта конфигурацияланған логикалық көлемдерге (айна емес) құрылғыларды қосу және жою мұндай мүмкіндіктерді жеткізушілер қарапайым түрде үндемейтін мәселелерге әкелетінін ескеріңіз. Мен нағыз құрылғылардағы фрагментация туралы айтып отырмын, ол құбыжық деңгейге жетуі мүмкін, ал виртуалды құрылғыда бәрі жақсы. Дегенмен, виртуалды құрылғылар ешкімді қызықтырмайды: барлығы сіздің нақты құрылғыларыңызда не болып жатқанына қызығушылық танытады. Бірақ ZFS тәрізді файлдық жүйелер (сондай-ақ LVM-мен бірге кез келген файлдық жүйелер) тек виртуалды диск құрылғыларымен жұмыс істейді (қол жетімді дискілік кеңістіктен виртуалды диск мекенжайларын бөлу, осы виртуалды құрылғыларды дефрагментациялау және т.б.). Және олар нақты құрылғыларда не болып жатқанын білмейді!
Енді виртуалды құрылғыңызда нөлдік фрагментация бар екенін елестетіп көріңіз (бұл жерде сізде тек бір үлкен ауқым бар дегенді білдіреді), сіз логикалық көлемге диск қосасыз, содан кейін логикалық көлемнен басқа кездейсоқ дискіні алып тастаңыз, содан кейін қайта теңестіріңіз. Және т.б., көп рет. Виртуалды құрылғыда әлі де сол бір дәрежеде болатынын анықтау оңай, бірақ нақты құрылғыларда жақсы ештеңе көрмейсіз.
Ең сорақысы, сіз бұл жағдайды түзете алмайсыз! Сіз жасай алатын жалғыз нәрсе - файлдық жүйеден виртуалды құрылғыны дефрагментациялауды сұрау. Бірақ ол сізге бәрі жақсы екенін айтады - бір ғана дәреже бар, фрагментация нөлге тең және бұл қаншалықты жақсы! Сонымен, блок деңгейінде конфигурацияланған логикалық көлемдер құрылғыларды қайта қосуға және жоюға арналмаған. Ең дұрысы, логикалық көлемді блок деңгейінде бір рет конфигурациялау керек, оны файлдық жүйеге тапсыру керек, содан кейін онымен басқа ештеңе жасамау керек.
Сонымен қатар, тәуелсіз FS және LVM ішкі жүйелерінің тіркесімі логикалық көлемдерді біріктіру үшін пайдаланылатын дискілердің әртүрлі сипатына мүмкіндік бермейді. Шынында да, сіз HDD және SSD дискілерінен логикалық көлемді жинадыңыз делік. Біріншісі дефрагментацияны қажет етеді, ал екіншісі қажет емес. Соңғысы үшін бас тарту сұрауларын шығару керек, ал біріншісі істемейді және т.б. Дегенмен, бұл комбинациямен мұндай селективтілікке жету өте қиын.
Файлдық жүйеде жеке LVM жасау жағдайды айтарлықтай жақсартпайтынын ескеріңіз. Шындығында, осылай жасау арқылы сіз оны болашақта жақсарту мүмкіндігін тиімді түрде жоясыз. Бұл өте жаман. Әртүрлі типтегі дискілер бір құрылғыда орналасуы мүмкін. Ал егер файлдық жүйе оларды ажыратпаса, кім ажыратады?
«Write-Anywhere» деп аталатын файлдық жүйелерде тағы бір мәселе жасырылады (бұл сонымен қатар орнату кезінде сәйкес транзакция үлгісін көрсетсеңіз, Reiser4 қамтиды). Мұндай файлдық жүйелер бұрын-соңды болмаған қуатты дефрагментация құралдарын ұсынуы керек. Төмен деңгейлі дыбыс реттеушісі бұл жерде көмектеспейді, тек кедергі жасайды. Мәселе мынада, мұндай менеджермен файлдық жүйеңіз тек бір құрылғының — виртуалды құрылғының тегін блок картасын сақтайды. Демек, виртуалды құрылғыны ғана дефрагментациялауға болады. Бұл сіздің дефрагментаторыңыз виртуалды мекенжайлардың кең, біртұтас кеңістігінде ұзақ уақыт бойы жұмыс істейтінін білдіреді.
Егер сізде кездейсоқ қайта жазуды орындайтын көптеген пайдаланушылар болса, мұндай дефрагментациялау құралының пайдасы жоққа шығарылады. Сіздің жүйеңіз сөзсіз баяулайды және сізде «үзілген дизайн» диагнозынан басқа ештеңе қалмайды. Бір мекенжай кеңістігінде жұмыс істейтін бірнеше дефрагментациялау бір-біріне кедергі жасайды. Әрбір нақты құрылғы үшін бөлек тегін блок картасын сақтасаңыз, бұл мүлдем басқа мәселе. Бұл сізге дефрагментация процесін тиімді параллельдеуге мүмкіндік береді.
Бірақ мұны тек жоғары деңгейлі логикалық көлем менеджерімен жасауға болады. Мұндай менеджерлері бар жергілікті файлдық жүйелер бұрын болмаған (кем дегенде, мен ешқайсысын білмеймін). Мұндай менеджерлер тек желілік файлдық жүйелерде (мысалы, GlusterFS) болды. Тағы бір маңызды мысал - көлемнің тұтастығын тексеру утилитасы (fsck). Әрбір ішкі том үшін бос блоктардың тәуелсіз картасын сақтасаңыз, логикалық көлемді тексеру процедурасын тиімді параллельдеуге болады. Басқаша айтқанда, жоғары деңгейдегі менеджерлермен логикалық көлемдер жақсырақ масштабталады.
Сонымен қатар, төмен деңгейлі дыбыс реттеушілері толыққанды суреттерді жасауға мүмкіндік бермейді. LVM және ZFS тәрізді файлдық жүйелермен сіз ғаламдық емес, тек жергілікті суретке түсіре аласыз. Жергілікті суреттер тек әдеттегі файл әрекеттерін лезде кері қайтаруға мүмкіндік береді. Логикалық көлемдегі операциялар (құрылғыларды қосу және жою) кері қайтарылмайды. Бір мысалды қарастырайық. Белгілі бір уақытта 100 файлды қамтитын екі құрылғыдан, А және В логикалық томы болғанда, сіз жүйенің S суретін түсіріп, содан кейін тағы жүз файл жасайсыз.
Осыдан кейін сіз дыбыс деңгейіне C құрылғысын қосасыз, ең соңында жүйені S суретіне қайтарыңыз. Сұрақ: S форматына оралғаннан кейін логикалық көлемде қанша файл мен құрылғы бар? Сіз болжағандай, 100 файл болады, бірақ үш құрылғы болады — бұл A, B және C құрылғылары бірдей, бірақ суретті жасау кезінде жүйеде тек екі құрылғы (A және B) болған. C құрылғысын қосу әрекеті кері қайтарылмады және егер сіз қазір C құрылғысын компьютерден алып тастасаңыз, ол деректеріңізді бұзады. Сондықтан оны алып тастамас бұрын алдымен C құрылғысынан барлық деректерді А және В құрылғыларына тарататын қайта теңестіру арқылы құрылғыны логикалық көлемнен алып тастау бойынша қымбат операцияны орындау қажет. Алайда, егер сіздің файлдық жүйеңіз жаһандық суреттерді қолдайтын болса, мұндай қайта теңестіру қажет болмас еді және S құрылғысына лезде кері қайтарылғаннан кейін, C құрылғысын компьютерден қауіпсіз алып тастауға болады.
Сонымен, жаһандық суреттердің сұлулығы мынада: олар құрылғыны деректердің үлкен көлемін қамтитын логикалық көлемнен (үшін) қымбат алып тастауды (қосуды) болдырмауға мүмкіндік береді (әрине, жүйеңіздің суретін қажет уақытта түсіруді ұмытпаңыз). Еске сала кетейік, суреттерді жасау және оларға файлдық жүйені қалпына келтіру - жедел орындалатын операциялар. Сізге сұрақ туындауы мүмкін: логикалық көлемдегі үш күндік операцияны қалай бірден қайтаруға болады? Бұл мүмкін! Файлдық жүйе дұрыс жобаланған жағдайда. Мен осы «3D суреттерінің» идеясын үш жыл бұрын ойлап таптым, ал өткен жылы мен бұл техниканы патенттедім.
Жергілікті файлдық жүйелер желілік файлдық жүйелерден үйренуі керек келесі нәрсе - желілік файлдық жүйелер оларды бөлек машиналарда (метадеректер серверлері деп аталатын) сақтайтын сияқты, метадеректерді бөлек құрылғыларда сақтау. Кейбір қолданбалар негізінен метадеректермен жұмыс істейді және бұл қолданбаларды метадеректерді қымбат, өнімділігі жоғары дискілерде сақтау арқылы айтарлықтай жеделдетуге болады. Файлдық жүйе және LVM көмегімен сіз соншалықты таңдаулы бола алмайсыз: LVM сіз берген блокта не бар екенін білмейді (деректер немесе метадеректер).
Төмен деңгейлі LVM-ді файлдық жүйеде енгізу сізге файлдық жүйе мен LVM комбинациясы бойынша көп күш-қуат бермейді, бірақ сіз өте жақсы істей алатын нәрсе файлдық жүйені шатастыруы сонша, оның кодымен жұмыс істеу мүмкін емес. Виртуалды құрылғыларға кірген ZFS және Btrfs - қабаттардың бұзылуы жүйені архитектуралық түрде бұзатынының айқын мысалдары. Сонымен, менің мақсатым не? Мәселе мынада, сіз өзіңіздің төмен деңгейлі LVM-ді файлдық жүйеде құрмауыңыз керек. Оның орнына, кейбір желілік файлдық жүйелер әртүрлі машиналармен (сақтау түйіндері) жасайтын сияқты құрылғыларды жоғары деңгейде логикалық томдарға біріктіру керек. Мойындау керек, олар мұны нашар алгоритмдерді қолданудың арқасында қорқынышты жасайды.
Абсолютті қорқынышты алгоритмдердің мысалдарына GlusterFS файлдық жүйесіндегі DHT аудармашысы және Ceph файлдық жүйесіндегі CRUSH картасы деп аталады. Мен көрген алгоритмдердің ешқайсысы қарапайымдылық пен жақсы масштабтауға қатысты мені қанағаттандырмады. Сондықтан мен алгебрамды есіме түсіріп, бәрін өзім ойлап табуға тура келді. 2015 жылы хэш-функцияларды қабаттаумен тәжірибе жасау кезінде мен өзіме сәйкес келетін нәрсені ойлап таптым және патенттемін. Осының барлығын іс жүзінде жүзеге асыру әрекетім сәтті болды деп айта аламын. Мен жаңа тәсілмен масштабтауға қатысты мәселелерді көрмеймін.
Иә, әрбір ішкі том жадта бөлек суперблок тәрізді құрылымды қажет етеді. Бұл шынымен де қорқынышты ма? Кім «мұхитты қайнататынын» және бір жергілікті машинада жүздеген мың немесе одан да көп құрылғылардың логикалық көлемін жасайтынын білмеймін. Егер біреу маған мұны түсіндіре алса, мен өте ризамын. Әзірге бұл мен үшін тек маркетингтік ақымақтық.
Ядро блогының құрылғысының ішкі жүйесіндегі өзгерістер (мысалы, blk-mq пайда болуы) файлдық жүйені енгізу талаптарына қалай әсер етті?
Олардың әсері болмады. Мен жаңа файлдық жүйені жобалауды қажет ететін блоктық қабатпен не болатынын білмеймін. Бұл ішкі жүйелер арасындағы интерфейс өте нашар. Драйвер жағынан файлдық жүйеге бірден-бір әсер блоктық қабат, содан кейін файлдық жүйе бейімделетін жаңа диск түрлерін енгізу болуы керек (reiser4 үшін бұл жаңа плагиндерді енгізуді білдіреді).
Жадтың жаңа түрлерінің пайда болуы (мысалы, SMR немесе SSD дискілерінің кең таралуы) FS дизайны үшін түбегейлі жаңа қиындықтарды білдіре ме?
Иә. Және бұл файлдық жүйені дамыту үшін қалыпты ынталандырулар. Қиындықтар әртүрлі және мүлдем күтпеген болуы мүмкін. Мысалы, енгізу/шығару өнімділігі деректер бөлігінің өлшеміне және оның ығысуына өте тәуелді болатын дискілер туралы естідім. Файлдық жүйе блогының өлшемі бет өлшемінен аспайтын Linux жүйесінде мұндай диск әдепкі бойынша өзінің толық мүмкіндіктерін көрсетпейді. Дегенмен, егер сіздің файлдық жүйеңіз дұрыс жасалған болса, одан көп нәрсені сығуға мүмкіндік бар.
Қазіргі уақытта сізден басқа қанша адам Reiser4 кодымен жұмыс істеп жатыр?
Мен қалағанымнан азырақ, бірақ мен қатты ресурс тапшылығын сезінбеймін. Мен Reiser4-тің даму қарқынына ризамын. Мен асығыс нәрселерді жоспарлап отырған жоқпын — бұл дұрыс аймақ емес. Мұнда «баяу және тұрақты жарыста жеңеді!» Заманауи файлдық жүйе ядроның ең күрделі ішкі жүйесі болып табылады және нашар дизайн шешімдері кейінгі жылдардағы жұмысты бұзуы мүмкін.
Волонтерлерден бірдеңені жүзеге асыруды сұрағанда, мен әрқашан олардың күш-жігері маңызды мақсаттарда қолдануға болатын дұрыс нәтижеге әкелетініне кепілдік беремін. Түсінгеніңіздей, мұндай кепілдіктер бірден және бірнеше рет болуы мүмкін емес. Сонымен қатар, жүздеген қолданушылар мен әзірлеушілерді алдап, жарамсыз болып көрінетін бағдарламалық жасақтаманың «мүмкіндіктерін» ұятсыз насихаттайтын, сөйте тұра ядро саммитінде күлімсіреп отыратын «іскерлерге» төзе алмаймын.
Кез келген компания Reiser4 әзірлеуге қолдау көрсетуге дайын екенін білдірді ме?
Иә, мұндай ұсыныстар болды, соның ішінде ірі сатушыдан. Бірақ ол үшін басқа елге көшуім керек еді. Өкінішке орай, мен енді 30-да емеспін, мен қалпақпен тұрып кете алмаймын.
Қазір Reiser4-те қандай мүмкіндіктер жетіспейді?
ReiserFS (v3) ішінде табылғанға ұқсас қарапайым томдарға арналған өлшемді өзгерту функциясы жоқ. DIRECT_IO жалаушасы бар файл операциялары да пайдалы болар еді. Сонымен қатар, көлемді бекітілген өлшемі жоқ және жеке томдар ретінде орнатуға болатын «семантикалық ішкі томдарға» бөлу мүмкіндігі жақсы болар еді. Бұл тапсырмалар қолдарын ластағысы келетін жаңадан бастағандар үшін жақсы.
Соңында, қарапайым іске асыру және басқару арқылы желілік логикалық көлемдерді көргім келеді (қазіргі алгоритмдер бұған мүмкіндік береді). Reiser4-те RAID-Z, скрабтар, бос кеңістік кэштері, 128-биттік айнымалылар және кейбір файлдық жүйе технологияларын әзірлеушілер арасында идеялардың жоқтығынан туындаған басқа да маркетингтік нонсенс ешқашан болмайды.
Қажет болуы мүмкін барлық нәрсені плагиндер арқылы жүзеге асыруға бола ма?
Егер біз тек интерфейстер және оларды жүзеге асыратын плагиндер (модульдер) туралы айтатын болсақ, бұл бәрі емес. Бірақ егер біз осы интерфейстерде қарым-қатынастарды енгізетін болсақ, онда барлық басқа нәрселерге қоса, бізде жоғары полиморфизмдер туралы түсініктер болады, содан кейін біз оны жасай аламыз. Объектіге бағытталған жұмыс уақыты жүйесін гипотетикалық түрде тоқтатып, нұсқау көрсеткішінің мәнін бірдей X интерфейсін жүзеге асыратын басқа плагинге көрсету үшін өзгертіп, одан кейін орындауды жалғастыру үшін жүйені босатуды елестетіңіз.
Егер соңғы пайдаланушы бұл «алмастыруды» байқамаса, онда жүйеде X интерфейсінде нөлдік ретті полиморфизм бар (немесе жүйе X интерфейсінде гетерогенді, бұл бірдей нәрсе) деп айтамыз. Егер сізде енді интерфейстер жиынтығы ғана емес, сонымен қатар олардың арасындағы байланыстар (интерфейс графигі) болса, онда белгілі бір интерфейстің «көршілестігінде» жүйенің гетерогенділігін сипаттайтын жоғары ретті полиморфизмдерді енгізуге болады. Мен мұндай классификацияны баяғыда енгізген едім, бірақ, өкінішке орай, мен оны жариялауға ешқашан жете алмадым.
Сонымен, плагиндерді және осы жоғары полиморфизмдерді пайдалана отырып, сіз кез келген белгілі мүмкіндікті сипаттай аласыз, сонымен қатар ешқашан айтылмағандарды «болжауға» болады. Мен мұны қатаң дәлелдей алмадым, бірақ мен қарсы мысалды әлі білмеймін. Негізі бұл сұрақ маған Феликс Кляйнның «Эрланген бағдарламасын» еске түсіреді. Ол бір кездері барлық геометрияны алгебраның бір тармағы ретінде көрсетуге тырысты (нақтырақ айтқанда, топ теориясы).
Енді негізгі сұраққа: Reiser4-тің негізгі ядроға жылжытуымен жұмыс қалай жүріп жатыр? Соңғы сұхбатта айтқаныңыздай, осы файлдық жүйенің архитектурасы туралы қандай да бір жарияланымдар болды ма? Бұл мәселе қаншалықты өзекті деп ойлайсыз?
Негізі, біз үш жыл бойы магистральдық желіге қосылуды сұрап келеміз. Рейзердің қосу сұрауын жасаған жалпыға ортақ тақырыптағы соңғы пікірі жауапсыз қалды. Сондықтан басқа сұрақтар біз үшін емес. Өз басым, мен неге белгілі бір операциялық жүйеге «біріктіру» керек екенін түсінбеймін. Linux біз үшін жалғыз орын емес. Сонымен, әртүрлі операциялық жүйелер үшін бірнеше порттары бар жеке репозиторий бар. Оны қажет ететін кез келген адам тиісті портты клондап, онымен қалағанын жасай алады (әрине лицензия аясында). Ал біреуге керек болмаса, бұл менің проблемам емес. Мен мұнымен «оны негізгі Linux ядросына жылжыту» мәселесін аяқтауды ұсынамын.
FS архитектурасы бойынша жарияланымдар өзекті, бірақ әзірге мен өзімнің жаңа нәтижелеріме ғана уақыт таптым, мен оны басымдылық деп санаймын. Тағы бір нәрсе, мен математикпін, ал математикада кез келген басылым теоремалар мен олардың дәлелдемелерінің қысқаша мазмұны болып табылады. Кез келген нәрсені дәлелсіз жариялау жаман форма болып саналады. Егер мен FS архитектурасы туралы кейбір бекітуді қатаң түрде дәлелдейтін болсам немесе жоққа шығаратын болсам, нәтижесінде пайда болған үйіндіні жеңу өте қиын болар еді. Бұл кімге керек? Сондықтан да болар, бәрі бұрынғы қалпында — бастапқы код пен оның түсініктемелерінде қалады.
Соңғы бірнеше жылда Reiser4-те қандай жаңалықтар болды?
Көптен күткен тұрақтылық ақыры жүзеге асты. Соңғылардың бірі «жоюға болмайтын» каталогтарды тудыратын қате болды. Мәселе оның тек атау хэшінің соқтығысуы контекстінде және ағаш түйініндегі нақты каталог жазбаларымен көрінуінде болды. Дегенмен, мен Reiser4-ті өндірісте пайдалану үшін әлі ұсына алмаймын: бұл біраз жұмысты және өндіріс жүйесінің әкімшілерімен белсенді ынтымақтастықты қажет етеді.
Ақырында мен бұрыннан келе жатқан идеяны жүзеге асыра алдым: бірнеше транзакция үлгілері. Бұрын Reiser4 тек жалғыз, қатаң кодталған транзакция үлгісін, McDonald-Reiser үлгісін қолдады. Бұл дизайн қиындықтарын тудырды. Атап айтқанда, бұл транзакция үлгісінде суретті алу мүмкін емес — олар атомның "ЖИНАҚТЫ ӨСТЕМЕ ЖАЗУ" құрамдас бөлігі арқылы бүлінуі мүмкін. Reiser4 қазір үш транзакция үлгісін қолдайды. Олардың бірінде (Write-Anywhere) атомның OVERWRITE SET құрамдас бөлігі тек қана жүйелік беттерді (дисктің растрлық кескіндері және т.б.) қамтиды, олар суретке түсірілмейді (тауық пен жұмыртқа мәселесі).
Осылайша, суреттерді енді жақсырақ енгізуге болады. Басқа транзакция үлгісінде барлық өзгертілген беттер тек ЖАСАУ ЖИНАҒЫНА (яғни, бұл таза журналға) ғана кіреді. Бұл модель Reiser4 бөлімдерінің жылдам фрагментациясына шағымданғандарға арналған. Енді осы үлгімен сіздің бөліміңіз ReiserFS (v3) нұсқасына қарағанда жылдамырақ бөлшектелмейді. Барлық үш қолданыстағы үлгілер кейбір ескертулермен операциялардың атомдылығына кепілдік береді, бірақ атомдық қасиетін жоғалтатын және тек бөлімнің тұтастығын сақтайтын модельдер де пайдалы болуы мүмкін. Мұндай модельдер осы функциялардың кейбірін атқаратын қолданбалардың барлық түрлері (деректер базалары және т.б.) үшін пайдалы болуы мүмкін. Бұл үлгілерді Reiser4-ке қосу өте оңай болар еді, бірақ мен мұны істеген жоқпын, өйткені ешкім мені сұрамаған және жеке маған қажет емес.
Метадеректерді бақылау сомасы пайда болды, мен жақында оларды «төмен құны» айналармен толықтырдым (әлі де тұрақсыз). Егер блоктың бақылау сомасы сәтсіз болса, Reiser4 реплика құрылғысынан сәйкес блокты дереу оқиды. ZFS және Btrfs мұны істей алмайтынын ескеріңіз; Олардың дизайны бұған жол бермейді. Мұндай жағдайларда «скраб» деп аталатын арнайы фондық сканерлеу процесін іске қосып, оның проблемалық блокқа жетуін күту керек. Бағдарламашылар мұндай шараларды бейнелі түрде «шешуші шешімдер» деп атайды.
Ақырында, ZFS, Btrfs, блоктық қабат және FS+LVM комбинациялары мүмкін емес нәрселердің барлығын ұсынатын гетерогенді логикалық томдар пайда болды — параллельді масштабтау, O(1) диск мекенжайының бөлгіші және ішкі томдар арасындағы мөлдір деректерді тасымалдау. Соңғысына пайдаланушы интерфейсі де қолдау көрсетеді. Енді сіз ең ыстық деректерді дыбыс деңгейіндегі ең жоғары өнімді дискіге оңай жылжыта аласыз.
Сонымен қатар, мұндай дискіге кез келген лас беттерді шұғыл түрде жууға болады, бұл fsync(2) қызметін жиі шақыратын қолданбаларды айтарлықтай жылдамдатады. Bcache деп аталатын блок қабатының функционалдығы мұндай икемділікті мүлде қамтамасыз етпейтінін атап өткен жөн. Жаңа логикалық томдар менің алгоритмдеріме негізделген (тиісті патенттер бар). Бағдарламалық қамтамасыз ету қазірдің өзінде айтарлықтай тұрақты; сынап көруге, өнімділікті өлшеуге және т.б. Жалғыз ыңғайсыздық мынада: әзірге дыбыс конфигурациясын қолмен жаңартып, оны бір жерде сақтау керек.
Мен жоспарларымның 10 пайызын ғана орындадым. Дегенмен, мен ең қиын тапсырма деп есептеген тапсырманы орындай алдым: логикалық көлемдерді reiser4 ішіндегі барлық кейінге қалдырылған әрекеттерді орындайтын флэш режимімен біріктіру. Мұның бәрі әлі эксперименттік «format41» филиалында.
Reiser4 xfstests тапсырады ма?
Кем дегенде, бұл мен үшін соңғы шығарылымды дайындаған кезде болды.
Плагиндердің көмегімен Reiser4-ті желілік (кластерлік) файлдық жүйеге айналдыру принципі мүмкін бе?
Бұл мүмкін, тіпті қажет! Егер дұрыс жобаланған жергілікті файлдық жүйеге негізделген желілік файлдық жүйені жасасаңыз, нәтиже шынымен де әсерлі болады! Мен кез келген жергілікті файлдық жүйені пайдалану арқылы жүзеге асырылатын заманауи желілік файлдық жүйелердің серверлік сақтау қабатына көңілім толмайды. Бұл қабаттың болуы мүлдем негізсіз. Желілік файлдық жүйе блоктық деңгеймен тікелей өзара әрекеттесуі керек және жергілікті файлдық жүйенің кез келген қосымша қызметтік файлдарды жасауын талап етпеуі керек!
Жалпы, файлдық жүйелерді жергілікті және желіге бөлу қате атау болып табылады. Ол осыдан отыз жыл бұрын қолданылған, әлі ештеңе ұсынылмаған алгоритмдердің жетілмегендігінен туындады. Бұл сонымен қатар қажет емес бағдарламалық қамтамасыз ету компоненттерінің (әртүрлі қызметтер және т.б.) пайда болуының себебі болып табылады. Ең дұрысы, ядро модулінен және әрбір машинада орнатылған пайдаланушы утилиталарының жиынтығынан тұратын бір ғана файлдық жүйе болуы керек — кластер түйіні. Бұл файлдық жүйе жергілікті және желілік болып табылады. Және басқа ештеңе жоқ!
Егер Reiser4 қосылған болса LinuxЕгер ештеңе шықпаса, мен FreeBSD үшін FS ұсынғым келеді (алдыңғы сұхбаттан үзінді: «...FreeBSD ... академиялық тамырларға ие... Бұл әзірлеушілермен ортақ тіл табатынымызды білдіреді»)?
Сонымен, біз жаңа ғана білгеніміздей, біз Linux-пен жақсы жұмыс істеп жатырмыз: ол үшін арнайы, жұмыс істейтін Reiser4 порты бар, ол біздің репозиторийдің негізгі тармағының бөлігі. Мен FreeBSD туралы ұмытқан жоқпын! Ұсынудан тартынбаңыз! Мен FreeBSD-тің қыр-сырын білетін кез келген адаммен тығыз жұмыс істеуге дайынмын. Айтпақшы, олардың қауымдастығы маған қатты ұнайтыны - шешімдерді тәуелсіз сарапшылардан тұратын ауыспалы кеңес қабылдайды, бұл жалғыз, тұрақты тұлғаның кекшесіне еш қатысы жоқ.
Пайдаланушылар қауымдастығын қалай бағалайсыз? Linux бүгін бе? Ол "поп" болып кетті ме?
Жұмыс бағытын ескере отырып, мен үшін мұны бағалау өте қиын. Мен көбінесе пайдаланушыларды қате туралы есептері мен бөлімді түзетуге сұрауларын аламын. Пайдаланушылар пайдаланушылар сияқты. Кейбіреулері көбірек білгіш, кейбіреулері азырақ. Барлығына бірдей қарайды. Егер пайдаланушы менің нұсқауларымды елемейтін болса, кешіріңіз: мен де оларды елемеймін.
Алдағы бес-он жыл ішінде файлдық жүйелердің эволюциясын болжау мүмкін бе? Файлдық жүйені әзірлеушілер алдында тұрған негізгі қиындықтар қандай деп ойлайсыз?
Иә, мұндай болжам жасау қиын емес. Ұзақ уақыт бойы жоғары ағындық кеңістікте файлдық жүйелердің дамуы болған жоқ. Тек болып жатқан сияқты. Жергілікті файлдық жүйені әзірлеушілер нашар дизайнмен байланысты мәселелерге тап болады. Бұл жерде ескерту қажет. Мен «сақтау», «жылтыратылған» және портинг кодын әзірлеу деп санамаймын. Мен «Btrfs» деп аталатын түсінбеушілікті мен түсіндірілген себептерге байланысты даму деп санамаймын.
Әрбір патч тек өз проблемаларын нашарлатады. Әрқашан оны «жұмыс істейтін» «евангелистер» бар. Бұл негізінен мектеп оқушылары мен студенттердің лекцияны өткізіп жіберуі. Елестетіп көріңізші: оның нұсқасы жұмыс істейді, бірақ профессор жұмыс істемейді. Қандай адреналин! Менің ойымша, ең үлкен зиян Btrfs-тің ғажайып мүмкіндіктерін systemd, docker және т.
Енді бес-он жылдық болжам жасауға тырысайық. Мен Reiser4-те не істейтінімізді қысқаша сипаттадым. Жергілікті файлдық жүйені әзірлеушілер үшін негізгі қиындық (иә, бұл қазірдің өзінде) өмір сүру үшін лайықты жұмыс істеу мүмкін еместігі болады. Деректерді сақтауға арналған ешқандай идеяларсыз олар VFS, XFS және ext4 қателерін түзетуге тырысады. VFS жағдайы осы фонға қарсы әсіресе күлкілі, аспазсыз және оның болашағы жоқ мейрамхананың құтырған модернизациясын еске түсіреді.
Енді VFS коды бірнеше жад беттерін бір уақытта шартсыз түрде құлыптайды және негізгі файлдық жүйеден оларда жұмыс істеуді сұрайды. Бұл жою операциялары кезінде Ext4 өнімділігін жақсарту үшін енгізілді, бірақ сіз оңай түсінетіндей, мұндай бір уақытта құлыптау озық транзакциялық модельдермен мүлдем үйлеспейді. Бұл дегеніміз, ядроға қандай да бір ақылды файлдық жүйені қолдауды қосу мүмкін емес. Басқа салаларда жағдай қалай екенін білмеймін. LinuxБірақ файлдық жүйелерге келгенде, мұндағы кез келген әзірлеме Торвальдстың іс жүзінде жүргізіп отырған саясатымен үйлеспейді (академиялық жобалар шығарылады, ал В-ағашының не екенін білмейтін алаяқтарға шексіз несие беріледі). Сондықтан баяу ыдырау бағыты белгіленді. Әрине, олар мұны «даму» ретінде көрсетуге тырысады.
Әрі қарай, файлдық жүйенің «кастодиандары» тек сақтаудың артық болмайтынын түсініп, өз күштерін тиімдірек кәсіпорындарда сынап көреді. Олар әдетте таратылған файлдық жүйелерді және виртуалдандыруды қамтиды. Мүмкін олар сәнді ZFS-ті ол әлі жоқ басқа жерлерге апарады. Бірақ барлық жоғары ағындық файлдық жүйелер сияқты, бұл шыршаға ұқсайды: үстіне бірнеше қосымша биттерді іліп қоюға болады, бірақ тереңірек бара алмайсыз. Мен ZFS-пен күрделі кәсіпорын жүйесін құру мүмкін екенін мойындаймын, бірақ біз болашақты талқылап жатқандықтан, ZFS бұл жағынан үмітсіз екенін өкінішпен айта аламын: өздерінің виртуалды құрылғыларымен бұл балалар өздерінің және болашақ ұрпақтың одан әрі дамуы үшін оттегін үзді. ZFS - кешегі жаңалық. Ал ext4 және XFS енді кешегі күн емес.
Көп айтылып жүрген «тұжырымдамасын» бөлек атап өткен жөн.Linux «келесі ұрпақтың файлдық жүйесі». Бұл толығымен саяси және маркетингтік жоба, былайша айтқанда, «файлдық жүйелердің болашағына көз жеткізу» үшін жасалған. Linux нақты кейіпкерлер үшін. Мәселе мынада, бұрын ол Linux Бұрын ол «тек көңіл көтеру үшін» болған. Қазір ол негізінен ақша табу машинасына айналды. Ақша кез келген нәрседен табылады. Мысалы, жақсы бағдарламалық өнімді жасау өте қиын, бірақ ақылды «әзірлеушілер» мүлдем күш жұмсаудың қажеті жоқ екенін бұрыннан түсінген: тіпті барлық қоғамдық іс-шараларда жарияланып, жарнамаланатын жоқ бағдарламалық жасақтаманы да сәтті сатуға болады — ең бастысы - презентация слайдтарында көптеген мүмкіндіктер болуы керек.
Файлдық жүйелер бұл үшін өте қолайлы, өйткені нәтижені он жыл күтумен оңай келісе аласыз. Егер біреу кейінірек нәтижелердің жоқтығына шағымданса, олар файлдық жүйелерді түсінбейді! Бұл пирамидалық схеманы еске түсіреді: жоғарыда бәрін бастаған алаяқтар, содан кейін «дивидендтер жинайтын» бақытты аз адамдар, яғни даму үшін қаржы алып, жоғары жалақы алатын басқару жұмыстарын табады, конференцияларда атын шығарады және т.б.
Одан кейін «жолы болмағандар» келеді: олар өз шығындарын есептейді, жарамсыз бағдарламалық қамтамасыз етуді өндіріске енгізудің салдарымен күреседі және т.б. Олардың саны бұдан да көп. Ал пирамиданың негізінде пайдасыз кодты «кесетін» әзірлеушілердің орасан зор массасы жатыр. Олар ең көп жоғалтқандар, өйткені босқа кеткен уақытты қалпына келтіру мүмкін емес. Мұндай пирамидалар Торвальдс пен оның жақындары үшін өте тиімді. Және бұл пирамидалар неғұрлым көп болса, соғұрлым олар үшін жақсы. Мұндай пирамидаларды толтыру үшін өзегіне кез келген нәрсені қабылдауға болады. Әрине, олар мұның керісінше екенін көпшілік алдында мәлімдейді. Бірақ мен сөзбен емес, іспен бағалаймын.
Сонымен, «Linux файлдық жүйелерінің болашағы» тағы бір жоғары бағаланған, бірақ қолдануға жарамсыз бағдарламалық жасақтама бөлігі болып табылады. Btrfs-тен кейін бұл «болашақтың» орнына Bcachefs келуі ықтимал, бұл тағы бір будандастыру әрекеті. Linux Файлдық жүйесі бар блоктық қабат (жаман мысал жұқпалы). Қызығы, оның Btrfs сияқты мәселелері бар. Мен бұған ұзақ уақыт бойы күдіктендім, содан кейін кодты қараудан бас тарта алмадым - және бұл рас!
Bcachefs және Btrfs авторлары өздерінің файлдық жүйелерін жасау кезінде басқа адамдардың бастапқы кодын белсенді түрде қайта пайдаланды, оның аздығын түсінді. Жағдай балалардың «телефон» ойынын еске түсіреді. Мен бұл кодтың ядроға қалай қосылатынын шамамен елестете аламын. Ешкім іс жүзінде «тұңқырларды» байқамайды (барлығы оларды кейінірек басады). Кодтау стилі, жоқ бұзушылықтар туралы айыптаулар және т.б. туралы көптеген шиеленістерден кейін автордың «адалдығы», олардың басқа әзірлеушілермен қаншалықты «өзара әрекеттесетіні» және мұның бәрін корпорацияларға қаншалықты сәтті сата алатыны туралы қорытынды жасалады.
Соңғы нәтиже ешкімді қызықтырмайды. Жиырма жыл бұрын солай болуы мүмкін, бірақ қазір басқаша сұрақтар қойылуда: келесі он жылда белгілі бір адамдар жұмысқа орналасатындай етіп дамыту мүмкін бе? Ал соңғы нәтиже туралы сұрау, өкінішке орай, орындалған нәрсе емес.
Жалпы, мен өз файлдық жүйеңізді нөлден бастап ойлап табуға кеңес бермеймін. Тіпті он жыл ішінде бәсекеге қабілетті нәрсеге қол жеткізу үшін айтарлықтай қаржылық инвестиция жеткіліксіз болады. Әрине, мен ядроны біріктіруге арналған емес, маңызды жобалар туралы айтып отырмын. Сонымен, өз атын шығарудың тиімді жолы – біз сияқты нақты даму күштеріне қосылу. Бұл, әрине, оңай емес, бірақ бұл кез келген жоғары профильді жобада болады.
Алдымен мен қоятын мәселені шешуіңіз керек. Сосын сіздің байыпты екеніңізге көзім жеткен соң, мен көмектесе бастаймын. Дәстүр бойынша біз тек өз әзірлемелерін пайдаланамыз. Ерекшеліктер - қысу алгоритмдері және кейбір хэш функциялары. Біз әзірлеушілерді конференцияларға жібермейміз, содан кейін көптеген стартаптарда жиі кездесетіндей, басқа адамдардың идеяларын («мүмкін бірдеңе болатын шығар») біріктірмейміз.
Біз барлық алгоритмдерді өзіміз жасаймыз. Қазіргі уақытта мен деректерді сақтау ғылымының алгебралық және комбинаторлық аспектілеріне қызығушылық танытамын. Атап айтқанда, шекті өрістер, асимптотика және теңсіздіктер. Кәдімгі бағдарламашылар үшін де жұмыс бар, бірақ мен сізді бірден ескертуім керек: «басқа файлдық жүйені қарап, солай істеу» туралы барлық ұсыныстар еленбейді. Тығыз интеграцияға бағытталған патчтар Linux VFS желісі арқылы.
Сонымен, бізде ешқандай қателіктер жоқ, бірақ біз қайда бару керектігін түсінеміз және бұл дұрыс бағыт екеніне сенімдіміз. Бұл түсінік көктен манна ретінде келген жоқ. Естеріңізге сала кетейін, бізде 29 жылдық даму тәжірибеміз, нөлден бастап жазылған екі файлдық жүйе және деректерді қалпына келтіруге арналған көптеген утилиталар бар. Және бұл өте көп!
Ақпарат көзі: opennet.ru
