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