Reiser4 файлдык системасын иштеп чыгуучу Эдуард Шишкин менен экинчи маеги жарыяланды.
Баштоо үчүн окурмандарга кайда жана ким үчүн иштегениңизди эскертип коюңуз.
Мен Huawei Technologies, Германиянын изилдөө борборунда башкы сактоочу архитектор болуп иштейм. Виртуалдаштыруу бөлүмүндө мен маалыматтарды сактоонун ар кандай аспектилери менен алектенем. Менин иш-аракеттерим белгилүү бир операциялык системага байланыштуу эмес.
Учурда сиз негизги ядро бутагына киришип жатасызбы?
Абдан сейрек, эгерде менин жумуш берүүчүм талап кылса гана. Акыркы жолу болжол менен үч жыл мурун, мен 9p протоколунун жардамы менен хосттордо бөлүшүлгөн сактагычтын өткөрүү жөндөмдүүлүгүн жогорулатуу үчүн патчтарды жибердим (бул бизнестин дагы бир аталышы VirtFS). Бул жерде бир маанилүү белгилөө керек: мен Linux менен көптөн бери иштеп келе жатсам да, мен эч качан анын күйөрманы болгон эмесмин, башкача айтканда, мен башка бардык нерселердей эле “текшер дем алам”. Тактап айтканда, бир кемчиликти байкасам, эң көп дегенде бир жолу айта алам. Анан кимдир-бирөөнү ээрчип, аны көндүрө алышыңыз үчүн - андай болбойт.
Эсимде, акыркы жолу, он жыл мурун, сиз ядронун өнүгүү стилин катуу сынга алгансыз. Сиздин (же балким корпоративдик) көз карашыңыз боюнча, бир нерсе өзгөрдүбү, коомчулук жооп кайтардыбы же жокпу? Эгер андай болбосо, ким күнөөлүү деп ойлойсуз?
Мен эч качан жакшы жакка өзгөргөн жокмун. Коомчулуктун негизги көйгөйү – илимди саясий технологиялар, жеке мамилелер, көпчүлүктүн пикири, популизм, “ички үндөрдүн” кеңештери, чириген компромисс, илимден башка нерселер менен алмаштыруу. Информатика, эмне десек дагы, биринчи кезекте так илим. Ал эми кимдир бирөө "Linux way" желекчесинин астында же башка желектин астында 2x2 үчүн өз баасын жарыялай баштаса, анда бул зыяндан башка эч нерсе алып келбейт.
Бардык балээлер биринчи кезекте чечим чыгаргандардын компетентсиздигинен жана билимсиздигинен келип чыгат. Жетекчи компетентсиз болсо, ал объективдүү, адекваттуу чечим кабыл ала албайт. Ал да маданиятсыз болсо, ага туура кеңеш бере турган компетенттүү адис таба албайт. Чоң ыктымалдуулук менен тандоо "туура көрүнгөн нерселерди" айткан шылуунга түшөт. Коррупциялык чөйрө дайыма компетентсиз жалгыз лидерлердин айланасында өнүгөт. Анын үстүнө тарых бул жагынан эч кандай өзгөчөлүктү билбейт жана коомчулук мунун эң ачык ырастоосу.
Btrfs өнүгүүсүндөгү прогрессти кандай баалайсыз? Бул ФС балалык оорудан кутулдубу? Сиз аны кантип өзүңүзгө жайгаштырасыз - “үй үчүн” ФС катарыбы же корпоративдик колдонуу үчүнбү?
Мен андан кутулган жокмун. 11 жыл мурун айткандардын баары бүгүнкү күндө да актуалдуу. Btrfs менен болгон көйгөйлөрдүн бири, аны олуттуу муктаждыктар үчүн жараксыз кылат - бош орун маселеси. Башка FS бөлүмдө көп бош мейкиндикти көрсөтө турган жагдайларда колдонуучудан жаңы диск үчүн дүкөнгө чуркайт деп айткан жокмун. Бош орундун жетишсиздигинен логикалык көлөмдө операцияны бүтүрө албай калуу да эң жаман нерсе эмес. Эң жаманы, артыкчылыксыз колдонуучу дээрлик ар дайым, каалаган диск квоталарын айланып өтүп, бардыгын кыска убакыттын ичинде бош орундан ажырата алат.
Мындай көрүнөт (Linux ядросу 5.12 үчүн сыналган). Жаңы орнотулган системада скрипт ишке киргизилет, ал циклде үй каталогунда белгилүү аталыштар менен файлдарды түзөт, аларга белгилүү бир офсеттерде маалыматтарды жазат жана андан кийин бул файлдарды жок кылат. Бул сценарийди бир мүнөт иштеткенден кийин адаттан тыш эч нерсе болбойт. Беш мүнөттөн кийин, бөлүмдө ээлеген мейкиндиктин үлүшү бир аз көбөйөт. Эки-үч сааттан кийин ал 50% (15% баштапкы мааниси менен) жетет. Беш-алты саат иштегенден кийин, сценарий "бөлүмдө бош орун жок" деген ката менен бузулат. Ушундан кийин, сиз 4K файлды да бөлүмүңүзгө жаза албай каласыз.
Кызыктуу жагдай пайда болот: сиз бөлүмгө эч нерсе жазган жоксуз жана бардык бош орун (болжол менен 85%) бир жерде жок болуп кетти. Мындай чабуулга дуушар болгон бөлүмдүн анализи бир эле нерсени (ачкыч менен жабдылган объект), бир нече байт өлчөмүн камтыган көптөгөн дарак түйүндөрүн ачып берет. Башкача айтканда, мурда диск мейкиндигинин 15% ээлеген мазмун бүт бөлүмгө бирдей "сырап" болуп, жаңы файлды жазууга эч кандай жер калбай калды, анткени анын ачкычы бардык учурдагылардан чоңураак жана эркин Бөлүмдөгү блоктор түгөнүп калды.
Анын үстүнө, мунун баары негизги Btrfs конфигурациясында ишке ашат (эч кандай көз ирмемдик сүрөттөр, субтомдор ж.б. жок) жана сиз файлдын денелерин ошол FSде кантип сактоону чечкениңиз маанилүү эмес (даракта "фрагменттер" катары же экстент катары) форматталбаган блоктордун) - акыркы натыйжа бирдей болот.
Сиз башка агымдагы файл тутумдарын мындай чабуулга дуушар кыла албайсыз (алар сизге эмне десе да). Мен көйгөйдүн себебин көп убакыт мурун түшүндүргөм: бул Btrfsдеги B-дарагы концепциясын толугу менен бузуп, анын өзүнөн-өзү же атайылап бузулушуна жол ачат. Атап айтканда, белгилүү бир жүктөмдөрдүн астында сиздин файл тутумуңуз сырттан жардамсыз эле өз алдынча иштөө учурунда үзгүлтүксүз "жыгылып" калат. Ар кандай "басуу" фон процесстери күндү жеке столдордо гана сактай турганы түшүнүктүү.
Коллективдүү нерселерде серверлер Чабуулчу ар дайым алардан "алдыга озуп" чыга алат. Системалык администратор аларды ким кыйнап жатканын да аныктай албайт. Btrfs'те бул көйгөйдү чечүүнүн эң тез жолу - кадимки B-дарактын түзүмүн калыбына келтирүү, б.а., диск форматын кайра иштеп чыгуу жана Btrfs кодунун олуттуу бөлүгүн кайра жазуу. Иштеп чыгуучулар тиешелүү алгоритмдер жана маалымат структуралары боюнча баштапкы документтерди так аткарып, "Linux жолунда" адаттагыдай (жана сунушталгандай) "телефон" ойнотпой койгон деп эсептесек, мүчүлүштүктөрдү оңдоону кошкондо, бул 8-10 жылды талап кылат.
Бул жерде биз иштеп чыгуучулар мунун баарын түшүнүү үчүн талап кылынган убакытты да кошуубуз керек. Бул жерде кыйыныраак болот. Кандай болгон күндө да аларга түшүнүү үчүн 10 жыл аздык кылды. Ооба, ага чейин сиз бир керемет үмүт кыла албайт. Бул "сен жана мен билбеген" монтаждоо варианты же даярдоо үчүн "жөн эле бизнес маселеси" болгон жамаачы түрүндө болбойт. Ар бир мындай шашылыш "оңдоо" үчүн мен бузулуунун жаңы сценарийин сунуштайм. B-дарактар менин сүйүктүү темаларымдын бири, бул структуралар өздөрү менен эркиндикке чыдабайт деп айтышым керек!
Btrfs'ди өзүмө кантип жайгаштырам? Файлдык тутум деп атай албай турган нерсе катары, колдонулсун. Анткени, аныктама боюнча, FS - бул "диск мейкиндиги" ресурсун эффективдүү башкаруу үчүн жооптуу OS подсистемасы, биз Btrfs мисалында аны көрбөйбүз. Элестеткиле, сиз дүкөнгө жумушка кечигип калбоо үчүн саат сатып алганы келдиңиз, ал эми сааттын ордуна сизге таймери бар электр грильди эң көп дегенде 30 мүнөткө сатышты. Ошентип, Btrfs менен абал мындан да начар.
Почта тизмелерин карап отуруп, мен дисктердин арзандыгынан улам диск мейкиндигин натыйжалуу башкаруу актуалдуу болбой калды деген сөздү көп жолуктурам. Бул таптакыр болбогон нерсе. Натыйжалуу диск мейкиндигин башкаруучусу жок болсо, ОС алсыз жана жараксыз болуп калат. Сиздин машинаңыздагы дисктердин сыйымдуулугуна карабастан.
Мен RHELде Btrfs колдоосунун токтотулушу боюнча комментарий сурагым келет.
Бул жерде комментарий бере турган өзгөчө эч нерсе жок, баары абдан түшүнүктүү. Алар ошондой эле "технологиялык алдын ала көрүү" катары болгон. Ошентип, мен бул "алдын ала көрүү" аркылуу өткөн жокмун. Бул белги түбөлүккө илинип калбасын! Бирок алар толук колдоо менен кемчиликсиз долбоорду ишке киргизе алышпайт. RHEL ишкана, башкача айтканда, белгиленген товардык-акча мамилелери. Red Hat Btrfs почта тизмесиндегидей колдонуучуларды коркута албайт. Кырдаалды элестетип көргүлө: диск үчүн мээнет менен тапкан акчасын төлөгөн кардар, ошондой эле сизге колдоо көрсөтүү үчүн, ал эч нерсе жазбагандан кийин анын диск мейкиндиги кайда кеткенин түшүнгүсү келет. Буга эмне деп жооп бересиң?
Андан ары. Red Hat кардарларынын арасында белгилүү ири банктар жана биржалар бар. Btrfs'де айтылган аялуучулуктун негизинде алар DoS чабуулдарына дуушар болушса, эмне болорун элестетип көрүңүз. Буга ким жооптуу деп ойлойсуз? Автор эч нерсеге жооп бербейт деп жазылган GPL лицензиясынын сызыгын сөөмөйү менен көрсөтөм деп жаткандарга мен дароо айтам: "Жашыргыла!" Red Hat жооп берет, жана ал жетишсиз болуп көрүнгөн жол менен! Бирок мен Red Hat мындай көйгөйгө туш эмес экенин билем, анткени алардын QA инженерлеринин өзгөчө күчтүү командасы менен менин убагында тыгыз иштешүүгө мүмкүнчүлүк болгон.
Эмне үчүн кээ бир компаниялар Btrfs компаниясын ишканалардын өнүмдөрүндө колдой беришет?
Продукт аталышындагы "ишкана" префикси көп мааниге ээ эмес экенин эске алыңыз. Ишкана бул кардар менен келишимдик мамилелерде камтылган жоопкерчиликтин өлчөмү. Мен GNU/Linux негизиндеги бир гана ишкананы билем - RHEL. Калганынын баары, менин көз карашым боюнча, ишкана катары гана көрсөтүлөт, бирок бир эмес. Акыр-аягы, бир нерсеге суроо-талап бар болсо, анда сунуш дайыма болот (биздин учурда, бул айтылган "колдоо"). Баарына суроо-талап бар, анын ичинде. жана жараксыз программалык камсыздоо. Мындай суроо-талап кантип калыптанып, ага кимдер май тамызып жатканы башка тема.
Ошондуктан, Facebook өзүнүн серверлерине Btrf'терди орноткону тууралуу имиштер тарагандан кийин, мен эч кандай тыянак чыгарбайт элем. Андан тышкары, алардын даректери серверлер Жогоруда айтылган себептерден улам, мен муну кылдаттык менен жашырууну сунуштайт элем.
Эмне үчүн акыркы убакта XFS кодун тазалоого көп күч жумшалды? Анткени, адегенде бул үчүнчү тараптын файл системасы жана ext4 узак убакыт бою туруктуу жана мурунку бирдей туруктуу версиялардан үзгүлтүксүздүккө ээ. Red Hat XFSге кандай кызыгуусу бар? Максаты боюнча окшош эки файлдык системаны - ext4 жана XFSди активдүү иштеп чыгуунун мааниси барбы?
Буга эмне түрткү болгону эсимде жок. Демилге Red Hat кардарларынан чыгышы толук мүмкүн. Мындай изилдөөлөр жүргүзүлгөнү эсимде: өйдө жактагы кээ бир файлдык системаларда жаңы муундун жогорку класстагы дисктеринде көптөгөн объекттер түзүлгөн. Жыйынтыктарга ылайык, XFS ext4ке караганда жакшыраак жүрдү. Ошентип, алар аны эң келечектүү катары жайылта башташты. Кандай болгон күндө да мен бул жерден сенсациялуу эч нерсе издебейт элем.
Мен үчүн, алар самын менен бир авал алмаштырылган сыяктуу. Ext4 жана XFSди иштеп чыгуунун эч кандай мааниси жок. Экөө тең параллелдүү жана алардын ичинен каалаганын тандоо. Мындан эч кандай жакшылык чыкпайт. Табиятта өсүү үчүн көп мүмкүнчүлүктөр бар, бирок өсүүгө орун жок болгон учурлар көп болот. Бул учурда, ар кандай таң калыштуу жаңы өсүштөр пайда болот, аларга ар бир адам сөөмөйүн көрсөтөт («О, карачы, бул жашоодо эмнени көрбөйсүң!»).
Кабаттын бузулушу маселеси ext4, F2FSде шифрлөө функцияларынын пайда болушу менен (терс мааниде) чечилди деп ойлойсузбу (Btrfsдеги RAIDди айтпаганда да)?
Негизинен кандайдыр бир деңгээлдерди киргизүү жана алардын бузулбагандыгы жөнүндө чечим кабыл алуу адатта саясаттын иши болуп саналат жана мен бул жерде эч нерсеге комментарий берүүгө милдеттенбейм. Катмардын бузулушунун объективдүү аспектилери эч кимди анча кызыктырбайт, бирок биз алардын айрымдарын “жогорудан” бузуунун мисалында, тактап айтканда, блоктук катмарда болгон функцияларды ФСде ишке ашырууну карап көрсөк болот. Мындай "бузуу" сейрек учурларды эске алуу менен гана негиздүү. Ар бир мындай учур үчүн алгач эки нерсени далилдеш керек: бул чындап керек экенин жана муну менен системанын дизайнына зыян келтирилбейт.
Мисалы, салттуу түрдө блок катмары үчүн иш болгон күзгүлөрдү файл тутумунун деңгээлинде ишке ашыруу мааниси бар. Ар кандай себептер менен. Мисалы, "унчукпай" маалымат бузулушу (бит чирип) диск дисктерде пайда болот. Бул аппарат туура иштеп жатканда, бирок блок маалыматтары күтүлбөгөн жерден алыскы квазар чыгарган катуу гамма кванттын таасири астында бузулат. Эң жаманы, эгерде бул блок 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 боюнча: Мен жаратуучунун макаласын окудум. Кызыкпайт. Дагы, B-дарактар. Бул маалымат структурасы үмүтсүз эскирген. Биз аны өткөн кылымда таштап койгонбуз.
CephFS/GlusterFS/ж.б. сыяктуу тармактык кластердик FSтерге өсүп жаткан суроо-талапты кандай баалайсыз? Бул суроо-талап иштеп чыгуучулардын приоритеттеринин тармактык FSге өзгөрүшүн жана локалдык FSге жетишсиз көңүл бурууну билдиреби?
Ооба, приоритеттердин ушундай жылышуусу болду. Жергиликтүү файлдык системалардын өнүгүшү токтоп калды. Тилекке каршы, жергиликтүү томдор үчүн маанилүү бир нерсе жасоо азыр бир топ кыйын жана ар кимдин колунан келе бербейт. Алардын өнүгүүсүнө эч ким инвестиция салгысы келбейт. Бул коммерциялык уюмдан математикалык изилдөөлөр үчүн акча бөлүүнү суранганга барабар - алар сизден жаңы теорема боюнча кантип акча тапса болорун сурашат. Азыр жергиликтүү FS - бул сыйкырдуу түрдө "кутудан тышкары" жана "ар дайым иштеши керек" нерсе жана ал иштебесе, анда ал: "Ооба, алар эмне деп ойлоп жатышат!"
Мына ушундан улам жергиликтуу ФСтерге көңүл бурулбай жатат, бирок ал жакта дагы эле көп иштер бар. Ооба, баары мурунтан эле бар жергиликтүү файл тутумдарынын негизинде курулган бөлүштүрүлгөн сактагычка кайрылышты. Азыр абдан модалуу. "Чоң маалыматтар" деген сөз айкашы көптөгөн адамдар үчүн адреналинди пайда кылат, аны конференциялар, семинарлар, чоң айлыктар ж.б.
Тармактык файл тутумун колдонуучу мейкиндигинде эмес, ядро мейкиндигинде ишке ашыруу канчалык негиздүү?
Азырынча эч жерде ишке ашырыла элек абдан негиздүү мамиле. Жалпысынан алганда, тармактык файл системасы кайсы мейкиндикте ишке ашырылышы керек деген суроо "эки миздүү кылыч" болуп саналат. Келгиле, бир мисал карап көрөлү. кардар алыскы машинага маалыматтарды жазды. Алар анын баракчасынын кэшине кир барактар түрүндө түшүп калышты. Бул ядро мейкиндигинде "ичке шлюз" тармактык файл тутумунун жумушу. Андан кийин операциялык система эртеби-кечпи сизден ошол баракчаларды бошотуу үчүн дискке жазууну суранат. Андан кийин IO багыттоо (жөнөтүү) тармак FS модулу ишке кирет. Бул барактар кайсы сервердик машинага (сервер түйүнүнө) бараарын аныктайт.
Андан кийин тармактык стек ээлейт (жана, биз билгендей, ал ядро мейкиндигинде ишке ашырылат). Андан кийин, сервер түйүнү маалыматтар же метаберилиштер менен пакетти кабыл алат жана резервдик сактоо модулуна (б.а., ядро мейкиндигинде иштеген жергиликтүү FS) мунун баарын жаздырууга көрсөтмө берет. Ошентип, биз "жөнөтүү" жана "кабыл алуу" модулдары кайда иштеши керек деген суроону азайттык. Эгерде ошол модулдардын кайсынысы колдонуучу мейкиндигинде иштесе, бул сөзсүз түрдө контекстти алмаштырууга алып келет (ядро кызматтарын колдонуу зарылдыгынан улам). Мындай которгучтардын саны ишке ашыруунун деталдарынан көз каранды.
Эгерде мындай которгучтар көп болсо, анда сактоо өткөрүү жөндөмдүүлүгү (I/O өндүрүмдүүлүгү) төмөндөйт. Эгерде сиздин резервдик сактагычыңыз жай дисктерден турса, анда сиз олуттуу төмөндөөнү байкабай каласыз. Бирок, эгер сизде тез дисктер (SSD, NVRAM ж.б.) болсо, анда контексттик которуштуруу мурунтан эле "тоскоолдукка" айланат жана контекстти которууда үнөмдөө менен, өндүрүмдүүлүктү бир топ жогорулатса болот. Акчаны үнөмдөөнүн стандарттуу жолу модулдарды ядро мейкиндигине жылдыруу болуп саналат. Мисалы, биз 9p серверин QEMUден хост машинасындагы ядрого жылдыруу VirtFS көрсөткүчүнүн үч эсе жогорулашына алып келерин таптык.
Бул, албетте, тармактык ФС эмес, бирок ал нерселердин маңызын толугу менен чагылдырат. Бул оптималдаштыруу терс жагы көчүрүү маселелери болуп саналат. Кээ бирөөлөр үчүн, акыркы сын болушу мүмкүн. Мисалы, GlusterFSтин ядросунда такыр модулдары жок. Мунун аркасында ал азыр көптөгөн платформаларда, анын ичинде NetBSDде иштейт.
Жергиликтүү ФСлар тармактык концепциялардан кандай түшүнүктөрдү ала алат жана тескерисинче?
Бүгүнкү күндө, тармактык FS, эреже катары, жергиликтүү FS үстүнөн кошумчалары бар, ошондуктан мен акыркысынан бир нерсени кантип алууга болорун түшүнбөйм. Ооба, чындап эле, 4 кызматкерден турган компанияны карап көрөлү, анда ар ким өз ишин жасайт: бири бөлүштүрөт, экинчиси жөнөтөт, үчүнчүсү алат, төртүнчүсү дүкөндөр. Ал эми компания аны сактаган кызматкеринен эмнени карызга ала алат деген суроо кандайдыр бир деңгээлде туура эмес угулат (ал көптөн бери андан карыз алган нерсе бар).
Бирок жергиликтүү FS тармактыктардан үйрөнө турган көп нерсеге ээ. Биринчиден, сиз алардан логикалык көлөмдөрдү кантип жогорку деңгээлде бириктирүүнү үйрөнүшүңүз керек. Азыр деп аталган "Өркүндөтүлгөн" локалдык файл тутумдары LVMден алынган "виртуалдык түзүлүш" технологиясын колдонуу менен логикалык көлөмдөрдү топтойт (ZFSде биринчи жолу ишке ашырылган ошол эле инфекциялык катмар бузуу). Башкача айтканда, виртуалдык даректерди (блок номурларын) реалдуу даректерге жана кайра которуу төмөн деңгээлде (б.а., файл системасы киргизүү/чыгаруу өтүнүчүн чыгаргандан кийин) ишке ашат.
Блоктук катмарда жайгаштырылган логикалык көлөмгө (күзгүлөргө эмес) түзмөктөрдү кошуу жана алып салуу мындай "функцияларды" жеткирүүчүлөргө жөнөкөй унчукпай койгон көйгөйлөргө алып келерин эске алыңыз. Мен чыныгы түзмөктөрдө фрагментация жөнүндө айтып жатам, алар укмуштуудай маанилерге жете алат, ал эми виртуалдык түзмөктө баары жакшы. Бирок, виртуалдык түзүлүштөргө кызыккандар аз: бардыгы сиздин чыныгы түзмөктөрүңүздө эмне болуп жатканына кызыгышат. Бирок ZFS сыяктуу FS (ошондой эле LVM менен бирдикте каалаган FS) виртуалдык диск түзүлүштөрү менен гана иштейт (виртуалдык диск даректерин бош даректерден бөлүп, бул виртуалдык түзүлүштөрдү дефрагментациялоо ж.б.). Жана алар чыныгы түзмөктөрдө эмне болуп жатканын билишпейт!
Эми виртуалдык түзүлүштө нөлдүк фрагментация бар деп элестетиңиз (башкача айтканда, ал жерде сизде бир эле гигант бар), сиз логикалык көлөмүңүзгө диск кошосуз, андан кийин логикалык көлөмүңүздөн башка кокус дискти алып салып, андан кийин тең салмактуулукту түзөсүз. Жана көп жолу. Виртуалдык түзмөктө сиз дагы эле ошол эле деңгээлде жашай берериңизди элестетүү кыйын эмес, бирок чыныгы түзмөктөрдө сиз эч кандай жакшы нерсени көрбөйсүз.
Эң жаманы бул абалды оңдоого да кудуретиң жетпейт! Бул жерде сиз жасай турган жалгыз нерсе - файл тутумунан виртуалдык түзүлүштү дефрагментациялоону сураныңыз. Бирок ал сизге ал жерде баары сонун экенин айтат - бир гана даража бар, майдалануу нөлгө барабар жана мындан жакшыраак болушу мүмкүн эмес! Ошентип, блок деңгээлинде жайгаштырылган логикалык көлөмдөр түзмөктөрдү кайра-кайра кошуу/чыгаруу үчүн арналган эмес. Жакшы сөз менен айтканда, логикалык көлөмдү блок деңгээлинде бир жолу чогултуп, файл тутумуна берип, андан кийин аны менен башка эч нерсе кылбаңыз.
Мындан тышкары, көз карандысыз FS+LVM подсистемаларынын айкалышы логикалык көлөмдөр топтолгон дисктердин түрдүү мүнөзүн эске алууга мүмкүндүк бербейт. Чынында эле, сиз HDD жана катуу абалдагы түзмөктөрдөн логикалык көлөмдү чогулттуңуз дейли. Бирок анда биринчиси дефрагментацияны талап кылат, ал эми экинчиси талап кылбайт. Акыркысы үчүн, жокко чыгаруу өтүнүчтөрүн беришиңиз керек, бирок биринчиси үчүн эмес, ж.б. Бирок, бул айкалыштырууда мындай селективдүүлүктү көрсөтүү өтө кыйын.
Файлдык тутумда өзүңүздүн LVMиңизди түзгөндөн кийин, абал анча деле жакшырбайт. Мындан тышкары, муну менен сиз келечекте аны жакшыртуу мүмкүнчүлүгүнө чекит коёсуз. Бул абдан жаман. Ар кандай типтеги дисктер бир эле машинада жашай алат. Ал эми файл системасы аларды айырмалай албаса, анда ким айырмалайт?
Дагы бир көйгөй деп аталгандарды күтүүдө. "Write-Anywhere" файл тутумдары (эгер сиз орнотуу учурунда тиешелүү транзакция моделин көрсөтсөңүз, анда Reiser4 да кирет). Мындай файл системалары өз күчү боюнча болуп көрбөгөндөй дефрагментация куралдарын камсыз кылышы керек. Ал эми төмөнкү деңгээлдеги көлөм менеджери бул жерде жардам бербейт, бирок бир гана жолго чыгат. Чындыгында, мындай менеджер менен сиздин FS бир гана түзмөктүн акысыз блокторунун картасын сактайт - виртуалдык. Демек, сиз виртуалдык аппаратты гана дефрагментациялай аласыз. Бул сиздин дефрагментациялоочу виртуалдык даректердин чоң бир мейкиндигинде узак жана узак убакыт бою иштей тургандыгын билдирет.
Эгер сизде кокус кайра жазуу менен алектенген көптөгөн колдонуучулар болсо, анда мындай дефрагментациялоочунун пайдалуу эффектиси нөлгө чейин төмөндөйт. Сиздин системаңыз сөзсүз түрдө жайлай баштайт жана сиз "сынган дизайн" деген капаланган диагноздун алдында колуңузду бүктөй аласыз. Бир эле дарек мейкиндигинде иштеген бир нече дефрагментациялоочулар бири-бирине тоскоол болот. Ар бир реалдуу түзмөк үчүн акысыз блоктордун өз картасын сактасаңыз, бул таптакыр башка маселе. Бул дефрагментация процессин эффективдүү параллелизациялайт.
Бирок бул сизде жогорку деңгээлдеги логикалык көлөм менеджери болгондо гана жасалышы мүмкүн. Мындай менеджерлери бар локалдык файл тутумдары мурда болгон эмес (жок дегенде, мен алар жөнүндө билбейм). Мындай менеджерлер бир гана тармактык файл тутумдарына (мисалы, GlusterFS) ээ болгон. Дагы бир маанилүү мисал - бул көлөмдүн бүтүндүгүн текшерүү (fsck) утилитасы. Эгерде сиз өзүңүздүн көз карандысыз картаңызды ар бир субтом үчүн акысыз блокторду сактасаңыз, анда логикалык көлөмдү текшерүү процедурасын эффективдүү параллелдештирүүгө болот. Башкача айтканда, жогорку деңгээлдеги менеджерлер менен логикалык көлөм жакшыраак масштабда.
Мындан тышкары, төмөнкү деңгээлдеги көлөм менеджерлери менен сиз толук кандуу снапшотторду уюштура албайсыз. LVM жана ZFS сыяктуу файл тутумдары менен сиз жергиликтүү көз ирмемдерди гана тарта аласыз, бирок глобалдык сүрөттү эмес. Жергиликтүү көз ирмемдик сүрөттөр кадимки файл операцияларын гана артка кайтарууга мүмкүндүк берет. Жана эч ким логикалык көлөмдөгү операцияларды артка кайтарбайт (түзмөктөрдү кошуу/чыгаруу). Муну бир мисал менен карап көрөлү. Убакыттын өтүшү менен сизде 100 файлды камтыган А жана В эки түзмөктүн логикалык көлөмү болгондо, S тутумунун сүрөтүн тартып, андан кийин дагы жүз файлды түзөсүз.
Андан кийин, сиз С түзмөгүн үнүңүздүн көлөмүнө кошуп, акырында тутумуңузду кайра S сүрөткө түшүрөсүз. Суроо: S форматына кайтарылгандан кийин логикалык көлөмүңүз канча файлды жана түзмөктү камтыйт? Сиз ойлогондой 100 файл болот, бирок 3 түзмөк болот - булар бир эле A, B жана C түзмөктөр, бирок снапшот түзүлгөн учурда тутумда эки гана түзмөк (A жана B) болгон. ). С түзмөгүн кошуу операциясы артка жылган жок жана эгер сиз азыр С түзмөгүн компьютерден алып салсаңыз, ал сиздин маалыматыңызды бузуп салат, андыктан өчүрүүдөн мурун сиз адегенде аппаратты логикалык көлөмдү кайра баланстан алып салуу үчүн кымбат операция жасашыңыз керек болот. бардык маалыматтарды С түзмөгүнөн А жана В түзмөктөрүнө чачыратат. Бирок, эгер сиздин FS глобалдык снапшотторду колдосо, мындай тең салмактуулук талап кылынбайт жана S га заматта кайтарылгандан кийин, сиз С түзмөгүн компьютерден коопсуз алып салсаңыз болот.
Ошентип, глобалдык снапшоттор жакшы, анткени алар чоң көлөмдөгү маалыматы бар (албетте, тутумуңузду "сүрөткө алууну" унутпасаңыз, аппаратты логикалык көлөмдөн (логикалык көлөмгө) кымбат алып салуудан (кошуудан) качууга мүмкүндүк берет. керектүү убакта). Эсиңиздерге сала кетейин, көз ирмемдик сүрөттөрдү түзүү жана аларга файл тутумун артка жылдыруу - көз ирмемдик операциялар. Суроо туулат: кантип үч күнгө созулган логикалык көлөмдөгү операцияны заматта артка кайтарууга болот? Бирок бул мүмкүн! Эгер файл тутумуңуз туура иштелип чыккан болсо. Мен үч жыл мурун мындай "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-та, FS блогунун көлөмү барактын өлчөмүнөн ашпаса, мындай диск демейки боюнча өзүнүн толук мүмкүнчүлүктөрүн көрсөтпөйт. Бирок, эгерде сиздин файл тутумуңуз туура иштелип чыккан болсо, анда андан көп нерсени алууга мүмкүнчүлүк бар.
Учурда сизден башка канча адам Reiser4 коду менен иштеп жатат?
Мен каалагандан азыраак, бирок мен дагы ресурстардын жетишсиздигин сезбейм. Мен Reiser4тин өнүгүү темпи менен көбүрөөк канааттандым. Мен "ат айдаганга" барбайм - бул туура аймак эмес. Бул жерде, "эгер сен тынчыраак айдасаң, жүрө бересиң!" Заманбап файл системасы - бул эң татаал өзөктүк подсистема, анын туура эмес дизайн чечимдери адамдын кийинки жылдардагы эмгегин жокко чыгарышы мүмкүн.
Ыктыярчыларга бир нерсени ишке ашырууну сунуштоо менен, мен ар дайым күч-аракеттер, албетте, олуттуу муктаждыктар үчүн суроо-талапка ээ болгон туура натыйжага алып келерине кепилдик берем. Сиз түшүнгөндөй, бир эле учурда мындай кепилдиктер көп болушу мүмкүн эмес. Ошол эле учурда мен жүздөгөн колдонуучуларды жана иштеп чыгуучуларды алдап, ачык эле колдонууга жараксыз программалык камсыздоонун "функцияларын" уятсыздык менен илгерилетип, ошол эле учурда ядро саммиттеринде жылмайып отуруп алган "фигураларды" көтөрө албайм.
Кайсы бир компания Reiser4 иштеп чыгууну колдоого даяр экенин билдирди?
Ооба, мындай сунуштар болгон, анын ичинде. жана негизги сатуучудан. Бирок бул үчүн башка өлкөгө көчүүгө туура келди. Тилекке каршы, мен 30 жашта эмесмин, биринчи ышкырыкта эле ажырап кете албайм.
Учурда Reiser4те кандай функциялар жок?
ReiserFS(v3) ичинде табылгандай жөнөкөй томдор үчүн "өлчөмүн өзгөртүү" функциясы жок. Мындан тышкары, DIRECT_IO желеги менен файл операциялары зыян келтирбейт. Андан кийин, мен бир томду "семантикалык подтомдорго" бөлүп алгым келет, алар белгиленген өлчөмдөрү жок жана көз карандысыз томдор катары орнотулат. Бул көйгөйлөр "чыныгы нерседе" күчүн сынап көргүсү келген үйрөнчүктөр үчүн жакшы.
Акыр-аягы, мен жөнөкөй ишке ашыруу жана башкаруу менен тармактык логикалык көлөмгө ээ болгум келет (заманбап алгоритмдер буга жол берет). Бирок Reiser4 эч качан RAID-Z, скрабтар, бош мейкиндик кэштери, 128 биттик өзгөрмөлөр жана кээ бир файлдык тутумдарды иштеп чыгуучулардын арасында идеялардын жетишсиздигинин фонунда пайда болгон башка маркетингдик нонсенстерге ээ болбойт.
Керектүү нерселердин бардыгын плагиндер аркылуу ишке ашырууга болобу?
Эгерде биз аларды ишке ашыруучу интерфейстер жана плагиндер (модульдер) боюнча гана айтсак, анда баары эмес. Бирок, эгерде сиз дагы ушул интерфейстерде мамилелерди киргизсеңиз, анда башка нерселер менен катар сизде жогорку полиморфизмдердин түшүнүктөрү болот, алар менен буга чейин эле ала аласыз. Объектке багытталган иштөө убактысынын тутумун гипотетикалык түрдө тоңдуруп, ошол эле X интерфейсин ишке ашырган башка плагинди көрсөтүү үчүн нускама көрсөткүчүнүн маанисин өзгөрттүңүз, андан кийин системаны аткарууну улантуу үчүн тоңдурду деп элестетиңиз.
Эгерде акыркы колдонуучу мындай "алмашууну" байкабаса, анда биз система X интерфейсинде нөлдүк тартиптүү полиморфизмге ээ деп айтабыз (же система X интерфейсинде гетерогендүү, бул бир эле нерсе). Эгерде азыр сизде интерфейстердин жыйындысы гана болбостон, алар боюнча да өз ара мамилелер (интерфейс графиги) болсо, анда сиз каалаган интерфейстин "кошунасында" системанын гетерогендүүлүгүн мүнөздөй турган жогорку даражадагы полиморфизмдерди киргизе аласыз. Мен мындай классификацияны көптөн бери киргизгем, бирок, тилекке каршы, андай болгон эмес.
Ошентип, плагиндердин жана ушундай жогорку полиморфизмдердин жардамы менен сиз кандайдыр бир белгилүү функцияны сүрөттөп, ошондой эле эч качан айтылбагандарды "болжолдоо" аласыз. Мен муну так далилдей алган жокмун, бирок мен дагы каршы мисалды билбейм. Жалпысынан алганда, бул суроо Феликс Кляйндын "Эрланген программасын" эске салды. Бир убакта ал бардык геометрияны алгебранын бир тармагы катары көрсөтүүгө аракет кылган (тактап айтканда, топ теориясы).
Эми негизги суроого - Reiser4 негизги өзөккө жылдыруу кандай жүрүп жатат? Акыркы интервьюда сиз айткан бул файлдык системанын архитектурасы боюнча басылмалар болдубу? Сиздин көз карашыңыз боюнча бул суроо канчалык актуалдуу?
Негизинен үч жылдан бери негизги тармакка киргизүүнү суранып келебиз. Тартуу өтүнүчү жасалган коомдук жиптеги Рейзердин акыркы комментарийи жоопсуз калды. Демек, бардык суроолор биз үчүн эмес. Мен жеке түшүнбөйм, эмне үчүн биз белгилүү бир операциялык системага "бирикишибиз" керек. Linuxда жарык клин сыяктуу бириккен жок. Ошентип, өзүнчө репозиторий бар, анда ар кандай ОС үчүн бир нече филиал-порттор болот. Кимге керек болсо, тиешелүү портту клондоп, аны менен каалаганыңызды жасай алат (албетте, лицензиянын чегинде). Ооба, кимдир бирөө керек эмес болсо, анда бул менин көйгөй эмес. Ушул жерден мен “негизги Linux ядросуна жылдыруу” маселесин чечилген деп кароону сунуштайм.
FS архитектурасы боюнча басылмалар актуалдуу, бирок азырынча мен жаңы натыйжаларым үчүн гана убакыт таптым, муну мен артыкчылыктуу деп эсептейм. Дагы бир нерсе, мен математикмин, математика боюнча ар кандай басылмалар теоремалардын кыскача мазмуну жана алардын далилдери. Ал жерде эч нерсени далилсиз жарыялоо – жаман табиттин белгиси. Эгерде мен ФСнын архитектурасы жөнүндө кандайдыр бир билдирүүнү кылдат далилдеп же жокко чыгарсам, анда натыйжада ушундай үймөктөр пайда болуп, андан өтүү абдан кыйын болот. Кимге керек? Ушундан улам, балким, баары эски формасында кала берет - баштапкы код жана ага комментарийлер.
Акыркы бир нече жылда Reiser4то эмне жаңылык болду?
Көптөн күткөн туруктуулук акыры ишке ашты. Акыркы пайда болгондордун бири ката "жок кылынбас" каталогдорго алып келди. Кыйынчылык, ал аты хэш кагылышуунун фонунда жана дарак түйүндөрүндө каталог жазууларынын белгилүү бир жайгашкан жеринде гана пайда болгон. Бирок, мен дагы эле Reiser4 өндүрүшүн сунуштай албайм: бул үчүн сиз өндүрүш тутумунун администраторлору менен активдүү өз ара аракеттенүү менен кандайдыр бир иштерди жасашыңыз керек.
Акыры, биз көптөн бери келе жаткан идеябызды - ар кандай транзакция моделдерин ишке ашырууга жетиштик. Буга чейин, Reiser4 бир гана катуу коддолгон Macdonald-Reiser моделин иштеткен. Бул дизайн көйгөйлөрдү жаратты. Тактап айтканда, мындай транзакциялык моделде көз ирмемдик сүрөттөр мүмкүн эмес - алар "OVERWRITE SET" деп аталган атомдук компонент тарабынан бузулат. Reiser4 учурда үч транзакция моделин колдойт. Алардын биринде (Write-Anywhere) атомдук компоненти OVERWRITE SET тутум баракчаларын гана камтыйт (дисктин битмаптарынын сүрөттөрү ж.б.), аларды “сүрөткө тартууга” болбойт (тоок жана жумуртка маселеси).
Ошентип, сүрөттөрдү азыр эң жакшы жол менен ишке ашырууга болот. Башка транзакциялык моделде, бардык өзгөртүлгөн барактар OVERWRITE SET (б.а., бул, негизинен, таза журнал) гана барат. Бул модель Reiser4 бөлүктөрүнүн тез бөлүнүшүнө нааразы болгондор үчүн. Эми бул моделде сиздин бөлүмүңүз ReiserFS (v3) менен караганда тезирээк үзүлбөйт. Бар болгон үч модел тең кээ бир эскертүүлөр менен операциялардын атомдуулугуна кепилдик берет, бирок атомдуулугун жоготкон жана бөлүмдүн бүтүндүгүн гана сактаган моделдер да пайдалуу болушу мүмкүн. Мындай моделдер бул функциялардын кээ бирлерин мурунтан эле өзүнө алган тиркемелердин (маалымат базалары ж.б.) бардык түрлөрү үчүн пайдалуу болушу мүмкүн. Бул моделдерди Reiser4ке кошуу абдан оңой, бирок мен муну кылган жокмун, анткени менден эч ким сураган жок, жана жеке мен мунун кереги жок.
Метаберилиштерди текшерүү суммалары пайда болду жана мен жакында аларды "үнөмдүү" күзгүлөр менен толуктадым (дагы эле туруксуз материал). Эгерде кандайдыр бир блоктун текшерүү суммасы ишке ашпай калса, Reiser4 дароо реплика түзүлүшүнөн тиешелүү блокту окуйт. Белгилей кетсек, ZFS жана Btrfs муну кыла албайт: дизайн буга жол бербейт. Ал жерде сиз "скраб" деп аталган атайын фон сканерлөө процессин иштетип, көйгөйлүү блокко жеткенче күтүшүңүз керек. Программисттер мындай окуяларды каймана мааниде "балдак" деп аташат.
Акыр-аягы, ZFS, Btrfs, блок катмары, ошондой эле FS+LVM комбинациялары принципиалдуу түрдө камсыз кыла албаган нерселердин бардыгын сунуш кылган гетерогендүү логикалык көлөмдөр пайда болду - параллелдүү масштабдоо, O(1) диск дарегин бөлүштүргүч, подтомдордун ортосундагы ачык маалыматтардын миграциясы. Акыркысы да колдонуучу интерфейсине ээ. Эми сиз эң ысык маалыматтарды үнүңүздүн эң жогорку өндүрүмдүүлүгү бар дискке оңой жылдыра аласыз.
Мындан тышкары, мындай дискке ар кандай кир баракчаларды тез арада жууп салууга болот, ошону менен көбүнчө fsync(2) деп атаган тиркемелерди бир топ ылдамдатууга болот. Мен bcache деп аталган блок катмарынын функционалдуулугу мындай иш-аракет эркиндигин такыр камсыз кылбагандыгын белгилейм. Жаңы логикалык томдор менин алгоритмдериме негизделген (тиешелүү патенттер бар). Программалык камсыздоо буга чейин эле туруктуу, аны сынап көрүү, өндүрүмдүүлүктү өлчөө ж.б. Жалгыз ыңгайсыздык, азырынча сиз кол менен үндүн конфигурациясын жаңыртып, аны бир жерде сакташыңыз керек.
Азырынча мен өз идеяларымды 10 пайызга ишке ашыра алдым, бирок мен эң кыйын деп эсептеген нерсеге жетиштим - логикалык көлөмдөрдү reiser4 ичинде кийинкиге калтырылган бардык аракеттерди аткарган флеш процедурасы менен байланыштыруу. Мунун баары дагы эле эксперименталдык "format41" тармагында.
Reiser4 xfstest'тен өтөбү?
Жок дегенде бул мен үчүн акыркы релизди даярдап жатканда жасады.
Негизи плагиндерди колдонуп Reiser4 тармагын тармактык (кластердик) 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тун башка аймактарында абал кандай экенин билбейм, бирок файлдык тутумдарга келсек, бул жердеги кандайдыр бир өнүгүү Торвалдс иш жүзүндө жүргүзүп жаткан саясатка туура келбейт (академиялык долбоорлор четтетилип, шылуундар B-дарагы деген эмне экенин билбейм, чексиз ишеним кредиттери). Ошондуктан, жай ажыроо үчүн курс белгиленген. Албетте, аны «өнүгүш» деп айтууга болгон күчү менен аракет кылышат.
Андан тышкары, файл тутумдарынын "сактоочулары" сиз "сактоодон" көп пайда таппай турганыңызды түшүнүшүп, өз күчүн пайдалуураак бизнесте сынашат. Бул, эреже катары, бөлүштүрүлгөн файл системалары жана виртуалдаштыруу. Балким, алар модалуу ZFSди али жок башка жерге алып кетишет. Бирок ал, агымдын өйдө жагындагы бардык FS сыяктуу эле, жаңы жылдык балатыны элестетет: үстүнө башка майда нерселерди илип алсаңыз, анда тереңирээк кете албайсыз. Мен ZFS негизинде олуттуу ишкана системасын курууга болорун моюнга алам, бирок биз азыр келечекти талкуулап жаткандыктан, мен өкүнүчтүү түрдө ZFS бул жагынан үмүтсүз экенин айта алам: виртуалдык түзүлүштөрү менен балдар кычкылтекти үзүп салышты. андан ары өнүктүрүү үчүн өздөрү жана келечек муундар үчүн. ZFS өткөн нерсе. Ал эми ext4 жана XFS кечээки күн эмес.
"Кийинки муундун Linux файл системасы" деген сенсациялуу концепция жөнүндө өзүнчө сөз кылуу керек. Бул толугу менен саясий жана маркетингдик долбоор, мындайча айтканда, Linux'та белгилүү бир белгилердин артына "файлдык системалардын келечегин кадоо" мүмкүнчүлүгү үчүн түзүлгөн. Чындыгында, Linux мурда "жөн гана көңүл ачуу үчүн" болгон. Бирок азыр бул биринчи кезекте акча жасоочу машина. Алар бардык мүмкүн болгон боюнча жасалган. Мисалы, жакшы программалык продуктуларды түзүү абдан кыйын, бирок акылдуу "иштеп чыгуучулар" эчак эле чыңалуунун кереги жок экенин түшүнүшкөн: сиз коомчулуктун бардык түрлөрүнө жарыяланган жана жарнамаланган жок программалык камсыздоону ийгиликтүү сата аласыз. окуялар - негизги нерсе, презентация слайддары көбүрөөк "өзгөчөлүктөрдү" камтышы керек.
Файлдык системалар бул үчүн эң сонун, анткени сиз он жыл бою жыйынтык боюнча коопсуз соодалаша аласыз. Ооба, эгерде кимдир бирөө кийинчерээк бул натыйжанын жоктугуна нааразы болсо, анда ал файл тутумдары жөнүндө эч нерсе түшүнбөйт! Бул каржы пирамидасын эске салат: эң башында бул баш аламандыкты баштаган авантюристтер, ал эми «бактылуу» болгондор аз: алар «дивиденддерди алып салышкан», б.а. өнүктүрүү үчүн акча алган, менеджер болуп жакшы маянасы бар жумушка орношкон, конференцияларда "көрсөтүлгөн" ж.б.
Андан кийин "бактысыздар" келишет: алар жоготууларды эсептешет, жараксыз программалык продуктуну өндүрүшкө киргизүүнүн кесепеттерин чечишет, ж.б. Алардын дагы көптөрү бар. Ооба, пирамиданын базасында пайдасыз кодду "араган" иштеп чыгуучулардын чоң массасы бар. Алар эң чоң жоготуулар, анткени текке кеткен убакытты кайра кайтаруу мүмкүн эмес. Мындай пирамидалар Торвалдс жана анын шериктери үчүн абдан пайдалуу. Жана бул пирамидалар канчалык көп болсо, алар үчүн ошончолук жакшы. Мындай пирамидаларды азыктандыруу үчүн, өзөгүнө бардыгын алууга болот. Албетте, эл алдында тескерисин айтышат. Бирок мен сөз менен эмес, иш менен баа берем.
Ошентип, "Linux'тун файлдык тутумдарынын келечеги" дагы бир жогору көтөрүлгөн, бирок колдонууга кыйын программа. Btrfs'тен кийин, жогорку ыктымалдуулук менен, мындай "келечектин" орду Bcachefs тарабынан алынат, бул Linux блок катмарын файл системасы менен кесип өтүүгө дагы бир аракет (жаман мисал жугуштуу). Ал эми типтүү: Btrfs сыяктуу эле көйгөйлөр бар. Мен муну көптөн бери шектендим, анан кандайдыр бир жол менен туруштук бере албай, кодду карадым - бул чындык!
Bcachefs жана Btrfs авторлору FS түзүүдө башка адамдардын булактарын жигердүү колдонушкан, алар жөнүндө аз түшүнүшкөн. Кырдаал балдардын «сынган телефон» оюнун элестетет. Жана мен бул коддун ядрого кандайча кошуларын болжол менен элестете алам. Чынында, «тырмоолорду» эч ким көрбөйт (ар бир адам кийинчерээк басышат). Кодекстин стили, болбогон мыйзам бузуулар боюнча айыптоо ж.б.у.с. жөнүндө көптөгөн талаш-тартыштардан кийин, автордун “лоялдуулугу”, анын башка иштеп чыгуучулар менен канчалык “өз ара аракеттениши” жана мунун баары канчалык ийгиликтүү болоору жөнүндө тыянак чыгарылат. андан кийин корпорацияларга сатылат.
Жыйынтык эч кимди кызыктырбайт. Жыйырма жыл мурун, балким, мен кызыкмакмын, бирок азыр суроолор башкача коюлуп жатат: жакынкы он жылдын ичинде айрым адамдар иш менен камсыз болушу үчүн муну алдыга жылдыруу мүмкүнбү? Жана, тилекке каршы, акыркы натыйжага таң калуу салт эмес.
Жалпысынан, мен сиздин файлдык тутумуңузду нөлдөн баштап кайра ойлоп табуудан баш тартууну сунуштайт элем. Анткени он жылдын ичинде атаандаштыкка жөндөмдүү бир нерсе алуу үчүн олуттуу каржылык салымдар да аздык кылат. Албетте, мен ядрого "түртүлүүгө" арналгандар жөнүндө эмес, олуттуу долбоорлор жөнүндө айтып жатам. Демек, өзүңүздү билдирүүнүн эффективдүү жолу - бул биз сыяктуу реалдуу өнүгүүлөргө кошулуу. Бул, албетте, оңой эмес, бирок бул бардык жогорку деңгээлдеги долбоорлордо болот.
Биринчиден, мен сунуш кылган көйгөйдү өз алдынча жеңишиңиз керек. Ошондон кийин, сиздин ниетиңиздин олуттуулугуна ынанып, мен жардам бере баштайм. Салттуу түрдө биз өзүбүздүн иштеп чыгууларды гана колдонобуз. Өзгөчөлүктөр кысуу алгоритмдери жана кээ бир хэш-функциялар. Биз иштеп чыгуучуларды конференцияларга саякатка жөнөтпөйбүз, анан көпчүлүк стартаптарда адаттагыдай эле башка адамдардын идеяларын («балким эмне болот») айкалыштырбайбыз.
Бардык алгоритмдерди өзүбүз иштеп чыгабыз. Мен учурда маалыматтарды сактоо илиминин алгебралык жана комбинатордук аспектилерине кызыгам. Атап айтканда, чектүү талаалар, асимптотика, теңсиздиктин далили. Жөнөкөй программисттер үчүн дагы жумуш бар, бирок мен сизге дароо эскертишим керек: "башка ФСти карап, ошондой кылыңыз" деген бардык сунуштар этибарга алынбайт. VFS аркылуу Linux менен тыгыз интеграцияга багытталган патчтар да ал жакка барат.
Демек, бизде тырмоо жок, бирок биз кайда жылыш керек экенин түшүнөбүз жана бул багыт туура экенине ишенебиз. Бул түшүнүк асмандан манна түрүндө келген эмес. Эсиңиздерге сала кетейин, биздин артыбызда 29 жылдык өнүгүү тажрыйбабыз бар, эки файл системасы нөлдөн баштап жазылган. Жана ошол эле сандагы маалыматтарды калыбына келтирүү утилиталары. Жана бул көп!
Source: opennet.ru
