Reiser4 файлын системийг хөгжүүлэгч Эдуард Шишкинтэй хийсэн хоёр дахь ярилцлага нийтлэгдсэн байна.
Эхлэхийн тулд хаана, хэнээр ажиллаж байгаагаа уншигчдад сануул.
Би Германы судалгааны төвийн Huawei Technologies-д хадгалах сангийн ерөнхий архитектороор ажилладаг. Виртуалчлалын хэлтэст би өгөгдөл хадгалах янз бүрийн тал дээр ажилладаг. Миний ажил тодорхой үйлдлийн систем дээр төвлөрдөггүй.
Та одоо цөмийн үндсэн салбар руу орох гэж байна уу?
Маш ховор бөгөөд зөвхөн ажил олгогч үүнийг шаарддаг. Хамгийн сүүлд би гурван жилийн өмнө 9p протокол (мөн VirtFS гэгддэг) ашиглан хостууд дээр хуваалцсан хадгалах багтаамжийг нэмэгдүүлэхийн тулд засваруудыг илгээсэн. Энд нэг чухал тэмдэглэл: Би Линукстэй удаан хугацаанд ажиллаж байсан ч хэзээ ч Линуксыг шүтэн бишрэгч байгаагүй. Би бусад бүх зүйлд дуртай байдаг шиг тийм ч дуртай биш. Тодруулбал, хэрэв би алдаа анзаарвал хамгийн ихдээ нэг удаа зааж өгнө. Би хэн нэгний араас яваад дараа нь ятгах шаардлагагүй болно.
Хамгийн сүүлд арван жилийн өмнө та хөгжлийн үндсэн хэв маягт нэлээд шүүмжлэлтэй хандаж байсныг санаж байна. Таны (эсвэл магадгүй корпорацийн) хэтийн төлөвөөс ямар нэгэн зүйл өөрчлөгдсөн үү? Олон нийт илүү хариу үйлдэл үзүүлэх болсон уу? Хэрэв тийм биш бол таны бодлоор хэн буруутай вэ?
Би ямар ч эерэг өөрчлөлтийг хараагүй. Нийгэмлэгийн гол асуудал бол шинжлэх ухааныг улс төрийн технологи, хувийн харилцаа, олонхийн санал бодол, популизм, "дотоод дуу хоолой"-ны зөвлөгөө, ялзарсан буулт гэх мэтээр шинжлэх ухаанаас өөр зүйлээр орлуулах явдал юм. Компьютерийн шинжлэх ухаан, та үүнийг хэрхэн харсан ч хамаагүй, хамгийн түрүүнд нарийн шинжлэх ухаан юм. Хэрэв хэн нэгэн "2x2"-ийн 4-өөс ялгаатай утгыг тунхаглаж эхэлбэл, "...Linux "арга зам" эсвэл өөр ямар нэгэн байдлаар бол хор хөнөөлөөс өөр зүйл авчрах магадлал багатай.
Бүх бэрхшээл нь шийдвэр гаргах хүмүүсийн чадваргүй, боловсрол дутмаг байдлаас үүдэлтэй. Хэрэв удирдагч чадваргүй бол тэд бодитой, хангалттай шийдвэр гаргах чадваргүй болно. Хэрэв тэд бас соёлгүй бол тэдэнд зөв зөвлөгөө өгөх чадвартай мэргэжилтэн олдохгүй байна. Тэд "зөв юм ярьж байгаа юм шиг" луйварчин хүнийг сонгох магадлалтай. Чадваргүй ганцаардсан удирдагчид үргэлж өөрсдийнхөө эргэн тойронд авлигын хүрээг бий болгодог. Түүх үүнд үл хамаарах зүйл байхгүй бөгөөд нийгэм нь үүний хамгийн тод жишээ юм.
Btrfs хөгжүүлэлтийн ахиц дэвшлийг та хэрхэн үнэлж байна вэ? Энэ файлын систем нь шүд цоорох асуудлаасаа салсан уу? Та үүнийг гэрийн файлын систем эсвэл байгууллагын хэрэглээнд хэрхэн байрлуулах вэ?
Би түүнээс салаагүй. Миний 11 жилийн өмнө дурдсан бүхэн өнөөдөр ч хамааралтай хэвээр байна. Btrfs-тэй холбоотой асуудлуудын нэг нь үүнийг ноцтой ашиглахад тохиромжгүй болгодог нь чөлөөт зайны асуудал юм. Бусад файлын систем нь хуваалт дээр маш их сул зай харуулах тохиолдолд хэрэглэгч шинэ диск авахаар дэлгүүр рүү гүйхээс өөр аргагүй болдог. Хангалтгүй сул зайн улмаас логик эзлэхүүн дээр үйлдлийг дуусгаж чадахгүй байх нь хамгийн муу зүйл биш юм. Хамгийн муу зүйл бол давуу эрхгүй хэрэглэгч ямар ч дискний квотыг алгасаж, хүн бүрийн сул зайг бараг үргэлж хурдан шавхаж чаддаг явдал юм.
Энэ нь иймэрхүү харагдаж байна (цөмд туршигдсан) Linux 5.12). Шинээр суулгасан систем дээр гэрийн санд тодорхой нэртэй файлуудыг давталтаар үүсгэж, тодорхой офсет дээр тэдгээрт өгөгдөл бичиж, дараа нь эдгээр файлуудыг устгадаг скриптийг ажиллуулдаг. Энэ скриптийг ажиллуулснаас хойш нэг минутын дараа ер бусын зүйл тохиолддоггүй. Таван минутын дараа хуваалт дээрх эзлэгдсэн зай бага зэрэг нэмэгддэг. Хоёроос гурван цагийн дараа энэ нь 50% хүрдэг (анхны утга нь 15% байсан). Таваас зургаан цагийн дараа скрипт "хуваалт дээр сул зай байхгүй" гэсэн алдаатайгаар гацдаг. Үүний дараа та хуваалт руугаа 4K файл ч бичиж чадахгүй болно.
Сонирхолтой нөхцөл байдал үүссэн: та хуваалт руу юу ч бичээгүй бөгөөд бүх чөлөөт зай (ойролцоогоор 85%) алга болсон. Ийм халдлагад өртсөн хуваалтын дүн шинжилгээ нь зөвхөн нэг зүйл (түлхүүрээр тоноглогдсон объект), хэдхэн байт хэмжээтэй олон тооны модны зангилаануудыг илрүүлэх болно. Өөрөөр хэлбэл, өмнө нь дискний зайны 15%-ийг эзэлдэг байсан контент бүхэлдээ хуваалтад жигд "түрхсэн" тул шинэ файл бичих зай байхгүй, учир нь түүний түлхүүр нь одоо байгаа бүх файлуудаас том, хуваалт нь чөлөөт блокууд дууссан.
Түүнээс гадна, энэ бүхэн Btrfs-ийн үндсэн тохиргоонд аль хэдийн тохиолддог (ямар ч хормын хувилбар, дэд боть гэх мэт) бөгөөд та энэ FS-д файлын биетүүдийг хэрхэн хадгалахаа шийдэх нь хамаагүй (мод дахь "фрагментууд" эсвэл форматлагдаагүй блокуудын хэмжээгээр) - эцсийн үр дүн нь ижил байх болно.
Та бусад дээд талын файлын системийг ийм халдлагад өртөх боломжгүй (хэн ч танд юу ч хэлсэн). Асуудлын шалтгааныг би аль хэдийн тайлбарласан: Btrfs нь B модны тухай ойлголтыг бүрэн гажуудуулж, аяндаа эсвэл санаатайгаар доройтолд өртөмтгий болгодог. Тодруулбал, тодорхой ажлын ачаалалтай үед таны файлын систем гадны ямар ч тусламжгүйгээр ажиллах явцад өөрөө "унадаг". Бүх төрлийн "дарамтгай" суурь процессууд нь зөвхөн хувийн ширээний компьютер дээр өдрийг хэмнэх нь ойлгомжтой.
Хамтын дээр серверүүд Халдагч үргэлж тэднийг "урьдчилж" чадна. Системийн админ түүнийг хэн хүчирхийлж байсныг ч тодорхойлж чадахгүй. Btrfs дээрх энэ асуудлыг засах хамгийн хурдан арга бол ердийн B модны бүтцийг сэргээх, өөрөөр хэлбэл дискний форматыг дахин зохион бүтээж, Btrfs кодын чухал хэсгийг дахин бичих явдал юм. Хөгжүүлэгчид холбогдох алгоритм болон өгөгдлийн бүтцийн талаархи анхны баримт бичгүүдийг чанд дагаж мөрдөж, "эвдэрсэн утас"-ыг тоглуулаагүй тохиолдолд дибаг хийхийг оруулаад 8-10 жил шаардагдана.Linux зам".
Та мөн хөгжүүлэгчид энэ бүхнийг ойлгоход шаардагдах хугацааг нэмэх хэрэгтэй. Эндээс л илүү төвөгтэй болдог. Ямар ч байсан 10 жил тэдэнд үүнийг ойлгоход хангалтгүй байсан. Тэр болтол гайхамшигт найдаж болохгүй. Энэ нь "бидний мэдэхгүй байсан" холбох сонголт эсвэл "зүгээр л бялуу" гэсэн нөхөөс хэлбэрээр ирэхгүй. Ийм яаран "засах" болгонд би доройтлын шинэ хувилбарыг танилцуулах болно. B-мод бол миний дуртай сэдвүүдийн нэг бөгөөд эдгээр бүтэц нь эрх чөлөөг тэсвэрлэдэггүй гэдгийг би хэлэх ёстой!
Би Btrf-ийг хэрхэн байрлуулах вэ? Ашиглах нь бүү хэл файлын систем гэж нэрлэхийн аргагүй зүйл. Тодорхойлолтоор файлын систем нь дискний зайг үр ашигтай удирдах үүрэгтэй үйлдлийн системийн дэд систем бөгөөд энэ нь Btrfs-д байдаггүй. Дэлгүүрт очиж ажилдаа хоцрохгүйн тулд цаг худалдаж аваад оронд нь хамгийн ихдээ 30 минут ажиллах таймертай цахилгаан мах зарна гэж төсөөлөөд үз дээ. За, Btrfs-ийн хувьд байдал бүр ч дор байна.
Захидлын жагсаалтыг үзэж байхдаа хөтчүүд маш хямд тул дискний зайг үр дүнтэй удирдах нь хамааралгүй болсон гэсэн санааг би байнга олж хардаг. Энэ бол шал дэмий зүйл. Үр дүнтэй дискний зайны менежер байхгүй бол үйлдлийн систем нь таны машин дээрх хөтчүүдийн багтаамжаас үл хамааран эмзэг болж, ашиглах боломжгүй болно.
Би RHEL дахь Btrfs-ийн дэмжлэгийг дуусгах талаар тайлбар өгөхийг хүсч байна.
Энд сэтгэгдэл бичих нэг их зүйл алга; бүх зүйл тунгалаг. Энэ бол тэдний "технологийн урьдчилсан үзүүлбэр" байсан юм. За, тэр "урьдчилан үзэх"-ийг давж чадаагүй. Тэд энэ шошгыг үүрд хадгалж чадахгүй! Мөн тэд алдаатай, дагалдах дизайны бүтээгдэхүүнийг бүрэн дэмжлэгтэйгээр гаргаж чадахгүй. RHEL бол бараа, мөнгөний харилцааг тодорхойлсон аж ахуйн нэгж юм. Red Hat нь Btrfs захидлын жагсаалтад байгаа шиг хэрэглэгчдийг дээрэлхэж чадахгүй. Үүнийг төсөөлөөд үз дээ: дискний төлөө болон таны дэмжлэгийн төлөө шаргуу олсон мөнгө төлсөн үйлчлүүлэгч юу ч бичээгүйнхээ дараа дискний зай хаана болсныг мэдэхийг хүсч байна. Та тэдэнд юу хэлэх вэ?
Дараа нь. Red Hat-ийн үйлчлүүлэгчид нэр хүндтэй томоохон банк, биржүүд байдаг. Btrfs-ийн дээр дурдсан эмзэг байдалд үндэслэн DoS халдлагад өртвөл юу болохыг төсөөлөөд үз дээ. Таны бодлоор хэн хариуцлага хүлээх вэ? GPL лицензийн зохиогч нь хариуцлага хүлээхгүй гэсэн мөрийг зааж өгөх гэж байгаа хүмүүст би шууд хэлье: "Үүнийг нуу!" Red Hat хариу үйлдэл үзүүлэх бөгөөд энэ нь үнэхээр цочирдуулах болно! Гэхдээ миний үед нягт хамтран ажиллах боломж олдсон Чанарын хяналт шалгалтын инженерүүдийн хүчирхэг багийг харгалзан үзвэл Red Hat ийм асуудалд өртөх эрсдэлгүй гэдгийг би мэднэ.
Зарим компаниуд яагаад Btrfs-ийг аж ахуйн нэгжийн бүтээгдэхүүндээ үргэлжлүүлэн дэмждэг вэ?
Бүтээгдэхүүний нэрэнд байгаа "байгууллага" гэсэн угтвар нь тийм ч их утга агуулаагүй гэдгийг анхаарна уу. Байгууллага гэдэг нь үйлчлүүлэгчтэй байгуулсан гэрээний харилцаанд шингэсэн хариуцлагын хэмжүүр юм. Би GNU дээр суурилсан ганцхан аж ахуйн нэгжийг мэднэ.Linux — энэ бол RHEL. Миний бодлоор бусад бүх зүйл зүгээр л аж ахуйн нэгжийн дүр эсгэдэг ч тийм биш юм. Эцэст нь хэлэхэд, хэрэв ямар нэгэн зүйлд эрэлт байгаа бол нийлүүлэлт үргэлж байх болно (манай тохиолдолд энэ нь дээр дурдсан "дэмжлэг" юм). Эрэлт хэрэгцээ нь ашиглах боломжгүй програм хангамж зэрэг бүх зүйлд байж болно. Энэ эрэлт хэрхэн үүсдэг, хэн үүнийг өдөөдөг нь огт өөр сэдэв юм.
Тиймээс Фэйсбүүк сервер дээрээ Btrfs байршуулсан гэсэн цуурхал гарсны дараа би ямар ч дүгнэлт хийхгүй. Түүнээс гадна, тэдгээрийн хаягууд серверүүд Дээр дурдсан шалтгааны улмаас би үүнийг нууцлахыг зөвлөж байна.
Яагаад сүүлийн үед XFS кодыг өнгөлөхийн тулд маш их хүчин чармайлт гаргасан бэ? Эцсийн эцэст, энэ нь анхандаа гуравдагч талын файлын систем байсан бөгөөд ext4 нь удаан хугацаанд тогтвортой байсан бөгөөд өмнөх, ижил тогтвортой хувилбаруудын өв залгамжлалтай. Red Hat XFS-ийн сонирхол юу вэ? ext4 болон XFS гэсэн ижил зорилготой хоёр файлын системийг идэвхтэй хөгжүүлэх нь утга учиртай юу?
Үүний цаана ямар сэдэл байсныг би санахгүй байна. Энэ санаачилгыг Red Hat-ийн үйлчлүүлэгчид гаргасан байх бүрэн боломжтой. Ийм судалгаанууд байсныг би санаж байна: зарим нэг дээд талын файлын системийг ашиглан шинэ үеийн дээд зэрэглэлийн хөтчүүд дээр асар олон тооны объектуудыг бүтээсэн. Үр дүн нь XFS нь ext4-ээс илүү сайн ажилласан болохыг харуулсан. Тиймээс тэд үүнийг хамгийн ирээдүйтэй гэж сурталчилж эхлэв. Ямар ч байсан би энд ямар нэгэн сенсаацтай зүйл хүлээхгүй.
Миний бодлоор тэд нэг зүйлийг нөгөөгөөр сольсон. Ext4 болон XFS-ийг хөгжүүлэх нь утгагүй юм. Зэрэгцээ эсвэл аль нэг сонголттой. Үүнээс сайн зүйл гарахгүй. Хэдийгээр байгальд өсөх боломж их байгаа ч тэлэх чадваргүй нөхцөл байдал ихэвчлэн байдаг. Энэ тохиолдолд бүх төрлийн хачирхалтай, муухай шинэ өсөлт гарч ирдэг бөгөөд үүнийг хүн бүр зааж өгдөг ("Өө, энэ амьдралдаа харж болох бүх зүйлийг хараарай!").
Ext4, F2FS (Btrfs-д RAID гэхгүй) шифрлэлтийн функцүүд гарч ирснээр давхаргын зөрчлийн асуудал (сөрөг утгаараа) шийдэгдсэн гэж та бодож байна уу?
Ерөнхийдөө аливаа давхаргыг нэвтрүүлэх, зөрчих эсэх нь ихэвчлэн бодлогын чанартай байдаг тул би энэ талаар тайлбар хийхгүй. Давхаргын зөрчлийн объектив талууд нь хэний ч сонирхлыг татдаггүй, гэхдээ бид дээрээс доош чиглэсэн зөрчлийн жишээг ашиглан тэдгээрийн заримыг шалгаж болно, тухайлбал файлын систем дэх блок давхаргад аль хэдийн байгаа функцийг хэрэгжүүлэх. Ийм "зөрчил" нь зөвхөн ховор тохиолдлуудад зөвтгөгддөг. Ийм тохиолдол бүрийн хувьд та эхлээд хоёр зүйлийг батлах ёстой: энэ нь үнэхээр шаардлагатай бөгөөд энэ нь системийн дизайнд хор хөнөөл учруулахгүй.
Жишээлбэл, уламжлалт байдлаар блок давхаргад зориулагдсан толин тусгал нь файлын системийн түвшинд хэрэгжүүлэх нь зүйтэй юм. Үүнд янз бүрийн шалтгаан бий. Жишээлбэл, дискний хөтчүүд нь өгөгдлийн чимээгүй эвдрэлд өртөмтгий байдаг (бит ялзрах). Энэ нь төхөөрөмж зөв ажиллаж байгаа хэдий ч блок дахь өгөгдөл нь алс холын квазараас ялгарах хатуу гамма туяанд гэнэт гэмтсэн үед тохиолддог. Энэ блок нь файлын системийн блок (суперблок, битмап блок, хадгалах модны зангилаа гэх мэт) байх үед энэ нь зайлшгүй сандрахад хүргэдэг.
Блок давхаргын (RAID 1 гэж нэрлэгддэг) санал болгож буй толин тусгал нь энэ асуудлыг шийдэхгүй гэдгийг анхаарна уу. Эцсийн эцэст хэн нэгэн шалгалтын дүнг шалгаж, алдаа гарсан тохиолдолд хуулбарыг унших ёстой. Цаашилбал, зөвхөн бүх зүйл биш, зөвхөн мета өгөгдлийг тусгах нь утга учиртай юм. Зарим чухал өгөгдлийг (жишээлбэл, чухал програмуудын гүйцэтгэх файлууд) мета өгөгдөл болгон хадгалах боломжтой. Энэ тохиолдолд тэд ижил аюулгүй байдлын баталгааг хүлээн авдаг. Бусад өгөгдлийн хамгаалалтыг бусад дэд системүүдэд (магадгүй хэрэглэгчийн програмууд) шилжүүлэх нь утга учиртай - бид үүнд шаардлагатай бүх нөхцлийг хангасан.
Ийм "хямд өртөгтэй" толь нь бүхэлдээ боломжтой бөгөөд зөвхөн файлын системийн түвшинд үр дүнтэй хэрэгжих боломжтой. Гэсэн хэдий ч давхаргын зөрчил нь ямар нэгэн бичил харуурын ашиг тусын тулд дэд системийг давхар кодоор үймүүлэх явдал юм. Үүний тод жишээ бол файлын системд RAID-5-ийг хэрэгжүүлэх явдал юм. Ийм шийдлүүд (файлын систем доторх уугуул RAID/LVM) нь файлын системийг архитектурын хувьд устгадаг. Маркетингийн янз бүрийн луйварчид давхаргын зөрчлийг "бөөнөөр үйлдвэрлэсэн" гэдгийг тэмдэглэх нь зүйтэй. Анхны санаа дутагдаж байгаа тул зэргэлдээ түвшинд хэрэгжсэн функцуудыг дэд системд нэмж, шинэ, маш хэрэгтэй функц болгон танилцуулж, идэвхтэй сурталчилж байна.
Reiser4 нь "доорх" давхаргыг зөрчсөн гэж буруутгагдаж байсан. Файлын систем нь бусадтай адил цул биш, модульчлагдсан тул дээрх давхарга (VFS) хийх ёстой зүйлийг гүйцэтгэдэг гэсэн үндэслэлгүй таамаглал дэвшүүлсэн.
ReiserFS v3.6 болон жишээ нь JFS нас барсан гэж хэлж болох уу? Тэд сүүлийн үед цөмд бага анхаарал хандуулж байна. Тэд хуучирсан уу?
Энд бид програм хангамжийн бүтээгдэхүүн үхсэн гэж юу гэсэн үг болохыг тодорхойлох хэрэгтэй. Нэг талаас, тэдгээрийг амжилттай ашиглаж байгаа (эцсийн эцэст тэд ийм зорилгоор бүтээгдсэн) тиймээс тэд амьд байна. Нөгөөтэйгүүр, би JFS-ийн талаар ярьж чадахгүй (би сайн мэдэхгүй байна), гэхдээ ReiserFS (v3) нь шинэ чиг хандлагад дасан зохицоход маш хэцүү байдаг (практик дээр батлагдсан). Энэ нь хөгжүүлэгчид ирээдүйд JFS гэхээсээ илүү дасан зохицоход хялбар шийдэлд анхаарлаа хандуулна гэсэн үг юм. Энэ утгаараа харамсалтай нь архитектурын хувьд үхсэн. Би "хуучирсан" гэсэн нэр томъёог огт хэрэглэхгүй байсан. Энэ нь хувцасны шүүгээнд тохиромжтой, гэхдээ програм хангамжид тохирохгүй. Аливаа зүйлд дутуу, дээгүүр байх гэсэн ойлголт байдаг. ReiserFS v3 нь одоогоор бүх талаараа Reiser4-ээс доогуур байгаа боловч зарим төрлийн ажлын ачааллын хувьд энэ нь бусад бүх файлын системээс давж гардаг гэдгийг би баттай хэлж чадна.
Та Tux3 болон HAMMER/HAMMER2 (DragonFly BSD-д зориулсан FS) FS-ийн хөгжүүлэлтийн талаар мэдэх үү?
Тийм ээ, би мэднэ. Tux3 дээр би тэдний хормын хувилбарын технологийг ("хувилбартай заагч" гэж нэрлэдэг) сонирхож байсан ч Reiser4 дээр бид өөр замаар явах байх. Би хормын хувилбарын дэмжлэгийн талаар хэсэг хугацаанд бодож байсан бөгөөд үүнийг энгийн Reiser4 ботид хэрхэн хэрэгжүүлэхээ хараахан шийдээгүй байна. Хамгийн гол нь Охад Родегийн санал болгосон шинэхэн "залхуу" лавлагаа тоологч техник нь зөвхөн B хэлбэрийн модонд л ажилладаг. Бидэнд байхгүй. Залхуу тоолуур нь Reiser4-д ашиглагдаж буй өгөгдлийн бүтцэд тодорхойлогдоогүй бөгөөд тэдгээрийг хэрэгжүүлэхийн тулд хэн ч шийдэж чадаагүй байгаа алгоритмын тодорхой асуудлуудыг шийдвэрлэх шаардлагатай.
HAMMER-ийн талаар: Би бүтээгчийн нийтлэлийг уншсан. Энэ нь надад сонирхолгүй байсан. Дахин хэлэхэд, В мод. Энэхүү өгөгдлийн бүтэц нь найдваргүй хуучирсан. Өнгөрсөн зуунд бид үүнийг орхисон.
CephFS/GlusterFS/ гэх мэт сүлжээний кластер файлын системийн өсөн нэмэгдэж буй эрэлтийг та хэрхэн үнэлж байна вэ? Энэ эрэлт нь хөгжүүлэгчдийн тэргүүлэх чиглэлийг сүлжээний файлын систем рүү шилжүүлж, дотоод файлын системд анхаарал хандуулахгүй байгааг харуулж байна уу?
Тийм ээ, тэргүүлэх чиглэлийн ийм өөрчлөлт гарсан. Орон нутгийн файлын системийн хөгжил зогсонги байдалд орсон. Харамсалтай нь орон нутгийн хэмжээний хувьд чухал ач холбогдолтой зүйл хийх нь одоо маш хэцүү бөгөөд хүн бүр үүнийг даван туулж чадна. Тэдний хөгжилд хэн ч хөрөнгө оруулалт хийхийг хүсэхгүй. Энэ нь арилжааны байгууллагаас математикийн судалгаанд зориулж хөрөнгө гаргахыг гуйхтай бараг адил юм—тэд чамаас ямар ч угсаатангүйгээр шинэ теоремоор хэрхэн мөнгө олох талаар асуух болно. Одоо локал файлын систем нь "хайрцагнаас гарсан" бөгөөд "үргэлж ажиллах ёстой" ид шидтэй зүйл бөгөөд хэрэв тийм биш бол "Тэд хэнийг бодож байна вэ?"
Энэ талбарт асар их ажил хийгдэж байгаа ч локал файлын системд анхаарал хандуулдаггүй. Тийм ээ, хүн бүр одоо байгаа локал файлын систем дээр суурилуулсан түгээсэн хадгалах систем рүү хандсан. Энэ нь яг одоо моод болж байна. "Том өгөгдөл" гэсэн хэллэг нь олон хүмүүсийн адреналиныг өдөөж, үүнийг бага хурал, семинар, их цалин гэх мэт зүйлстэй холбодог.
Сүлжээний файлын системийг хэрэглэгчийн орон зайд биш харин цөмийн орон зайд хэрэгжүүлдэг хандлага нь зарчмын хувьд хэр үндэслэлтэй вэ?
Хаана ч хэрэгжээгүй маш боломжийн арга. Ерөнхийдөө сүлжээний файлын системийг хаана хэрэгжүүлэх вэ гэдэг нь хоёр талдаа иртэй сэлэм юм. Нэг жишээ авч үзье. Үйлчлүүлэгч нь алсын машин руу өгөгдөл бичдэг. Энэ нь хуудасны кэшэд бохир хуудас болж дуусдаг. Энэ бол цөмийн зай дахь сүлжээний файлын системийн "нимгэн гарц"-ын ажил юм. Эрт орой хэзээ нэгэн цагт үйлдлийн систем тэдгээр хуудсуудыг чөлөөлөхийн тулд диск рүү бичихийг хүсэх болно. Дараа нь сүлжээний файлын системийн IO дамжуулагч модуль ажиллаж эхэлнэ. Энэ нь эдгээр хуудсууд аль серверийн машин (серверийн зангилаа) дээр дуусахыг тодорхойлдог.
Дараа нь сүлжээний стек (бидний мэдэж байгаачлан цөмийн орон зайд хэрэгждэг) ажлыг авдаг. Дараа нь серверийн зангилаа өгөгдөл эсвэл мета өгөгдөл агуулсан пакетыг хүлээн авч, арын санах ойн модульд (өөрөөр хэлбэл цөмийн орон зайд ажиллаж байгаа локал файлын систем) бүгдийг бичихийг заадаг. Тиймээс бид "илгээх" болон "хүлээн авах" модулиуд хаана ажиллах ёстой вэ гэсэн асуултыг багасгасан. Хэрэв аль нэг модуль нь хэрэглэгчийн орон зайд ажилладаг бол энэ нь зайлшгүй контекст шилжүүлэлтэд хүргэдэг (цөмийн үйлчилгээг ашиглах хэрэгцээ шаардлагаас шалтгаалан). Ийм шилжүүлэгчийн тоо нь хэрэгжилтийн нарийн ширийн зүйлээс хамаарна.
Хэрэв ийм олон унтраалга байгаа бол хадгалах чадвар (оролтын гаралтын гүйцэтгэл) буурна. Хэрэв таны арын санах ой удаан дискнүүдээс бүрддэг бол та мэдэгдэхүйц бууралтыг анзаарахгүй. Гэхдээ хэрэв танд хурдан диск (SSD, NVRAM гэх мэт) байгаа бол контекст шилжүүлэгч нь саад тотгор болж, контекст шилжүүлэгчийг хэмнснээр гүйцэтгэлийг мэдэгдэхүйц нэмэгдүүлэх боломжтой. Үүнд хүрэх нийтлэг арга бол модулиудыг цөмийн орон зайд шилжүүлэх явдал юм. Жишээлбэл, бид 9p серверийг QEMU-аас хост цөм рүү шилжүүлснээр VirtFS-ийн гүйцэтгэл гурав дахин нэмэгдсэн болохыг олж мэдсэн.
Энэ нь мэдээжийн хэрэг сүлжээний файлын систем биш, гэхдээ энэ нь бүх зүйлийг ойлгох болно. Энэ оновчлолын сул тал нь зөөврийн асуудал юм. Зарим хүмүүсийн хувьд сүүлийнх нь шүүмжлэлтэй байж магадгүй юм. Жишээлбэл, GlusterFS-д цөмийн модулиуд огт байхгүй. Үүний ачаар одоо NetBSD зэрэг олон платформ дээр ажиллаж байна.
Орон нутгийн ТЭЗҮ-үүд сүлжээний FS-ээс ямар ойлголтыг зээлж болох вэ?
Өнөө үед сүлжээний файлын системүүд нь ихэвчлэн локал файлын системүүд дээр бүтээгдсэн байдаг тул хэн нэгэн хүн яаж сүүлийнхээс юу ч зээлж болохыг сайн ойлгохгүй байна. Нэг нь түгээдэг, нэг нь илгээдэг, нэг нь хүлээн авдаг, нэг нь дэлгүүр хэсдэг дөрвөн ажилтантай компанийг бодоод үзээрэй. Мөн дэлгүүрийн ажилтнаас компани юу зээлж болох вэ гэсэн асуулт арай зохисгүй мэт санагдаж байна (тэд түүнээс зээлж авах зүйлээ аль хэдийн авсан байсан).
Харин локал файлын системд сүлжээний файлын системээс суралцах зүйл их бий. Нэгдүгээрт, тэд логик эзлэхүүнийг хэрхэн өндөр түвшинд нэгтгэж сурах хэрэгтэй. Одоогийн байдлаар "дэвшилтэт" гэж нэрлэгддэг локал файлын системүүд нь зөвхөн LVM-ээс зээлсэн "виртуал төхөөрөмж" технологийг (ZFS-д анх хэрэгжүүлсэн халдварт давхаргын зөрчил) ашиглан логик эзлэхүүнийг нэгтгэдэг. Өөрөөр хэлбэл, виртуал хаягууд (блок дугаарууд) нь бодит хаяг руу хөрвүүлэгдэж, доод түвшинд (жишээ нь, файлын систем нь I/O хүсэлт гаргасны дараа).
Блокийн давхарга дээр тохируулсан логик эзлэхүүнд (толин тусгал биш) төхөөрөмжүүдийг нэмэх, хасах нь ийм функцийг үйлдвэрлэгчид даруухан чимээгүй байх асуудалд хүргэдэг гэдгийг анхаарна уу. Би бодит төхөөрөмж дээр хуваагдмал байдлын талаар ярьж байна, энэ нь аймшигтай түвшинд хүрч чаддаг бол виртуал төхөөрөмж дээр бүх зүйл хэвийн байна. Гэсэн хэдий ч виртуал төхөөрөмжүүд нь хэнд ч сонирхолгүй байдаг: хүн бүр таны бодит төхөөрөмж дээр юу болж байгааг сонирхож байна. Гэхдээ ZFS-тэй төстэй файлын системүүд (түүнчлэн LVM-тэй холбоотой аливаа файлын системүүд) зөвхөн виртуал дискний төхөөрөмжтэй ажилладаг (дискний боломжит зайнаас виртуал дискний хаягийг хуваарилах, эдгээр виртуал төхөөрөмжүүдийг дефрагментаци хийх гэх мэт). Мөн тэд бодит төхөөрөмж дээр юу болж байгааг мэдэхгүй байна!
Одоо таны виртуал төхөөрөмж тэг хуваагдалтай байна гэж төсөөлөөд үз дээ (та зөвхөн нэг аварга том хэмжээтэй байна гэсэн үг), та логик эзлэхүүндээ диск нэмж, дараа нь логик эзлэхүүнээс өөр санамсаргүй дискийг устгаад дараа нь дахин тэнцвэржүүлнэ. Гэх мэтчилэн олон удаа. Виртуал төхөөрөмж дээр тэр нэг хэмжээ хэвээр байх болно гэдгийг ойлгоход хялбар байдаг, гэхдээ та бодит төхөөрөмж дээр сайн зүйл олж харахгүй.
Хамгийн аймшигтай нь та энэ байдлыг засч залруулж чадахгүй! Таны хийж чадах цорын ганц зүйл бол файлын системээс виртуал төхөөрөмжийг дефрагментаци хийхийг хүсэх явдал юм. Гэхдээ энэ нь танд бүх зүйл зүгээр гэдгийг хэлэх болно - зөвхөн нэг хэмжээс байна, хуваагдал тэг байна, энэ нь аль болох сайн байна! Тиймээс блокийн түвшинд тохируулсан логик хэмжээ нь төхөөрөмжийг дахин нэмж, устгахад зориулагдаагүй болно. Хамгийн тохиромжтой нь та логик эзлэхүүнийг блокийн түвшинд зөвхөн нэг удаа тохируулж, файлын системд шилжүүлж, дараа нь өөр юу ч хийх ёсгүй.
Цаашилбал, бие даасан FS болон LVM дэд системүүдийн хослол нь логик эзлэхүүнийг нэгтгэхэд ашигладаг хөтчүүдийн өөр шинж чанарыг зөвшөөрдөггүй. Үнэн хэрэгтээ та HDD болон SSD-ээс логик эзлэхүүнийг цуглуулсан гэж бодъё. Эхнийх нь дефрагментаци шаарддаг бол сүүлийнх нь шаардлагагүй. Та сүүлчийнх нь татгалзах хүсэлт гаргах хэрэгтэй, харин эхнийх нь байхгүй гэх мэт. Гэсэн хэдий ч, ийм сонгомол чанарыг энэ хослолоор хангах нь нэлээд хэцүү байдаг.
Файлын системд өөрийн LVM үүсгэх нь нөхцөл байдлыг төдийлөн сайжруулахгүй гэдгийг анхаарна уу. Үнэн хэрэгтээ үүнийг хийснээр та ирээдүйд үүнийг сайжруулах боломжийг үр дүнтэй арилгадаг. Энэ бол маш муу. Нэг машин дээр өөр өөр төрлийн хөтчүүд байж болно. Хэрэв файлын систем нь тэдгээрийг хооронд нь ялгахгүй бол хэн ялгах вэ?
Өөр нэг асуудал нь "Хаана ч хамаагүй бичих" гэж нэрлэгддэг файлын системд нуугдаж байна (үүнд мөн Reiser4 багтана, хэрэв та холбох явцад тохирох гүйлгээний загварыг зааж өгсөн бол). Ийм файлын систем нь урьд өмнө хэзээ ч байгаагүй хүчирхэг дефрагментацийн хэрэгслийг санал болгох ёстой. Доод түвшний эзэлхүүний менежер энд тус болохгүй, харин зөвхөн саад болдог. Асуудал нь ийм менежертэй бол таны файлын систем зөвхөн нэг төхөөрөмжийн үнэгүй блок газрын зургийг хадгалах болно - виртуал төхөөрөмж. Иймээс та зөвхөн виртуал төхөөрөмжийг дефрагментаци хийх боломжтой. Энэ нь таны дефрагментатор виртуал хаягуудын өргөн уудам, нэгдсэн орон зайд удаан хугацаагаар ажиллах болно гэсэн үг юм.
Хэрэв танд санамсаргүй дарж бичих олон хэрэглэгчид байгаа бол ийм дефрагментерийн ашиг тусыг үгүйсгэх болно. Таны систем гарцаагүй удааширч, "загвар эвдэрсэн" гэсэн урам хугарах оношоос өөр юу ч үлдэхгүй. Нэг хаягийн орон зайд ажилладаг олон дефрагментерууд зөвхөн бие биендээ саад болно. Хэрэв та бодит төхөөрөмж бүрт тусдаа үнэгүй блокийн газрын зураг хөтлөх юм бол энэ нь огт өөр асуудал юм. Энэ нь дефрагментацийн процессыг үр дүнтэй зэрэгцүүлэх боломжийг танд олгоно.
Гэхдээ үүнийг зөвхөн өндөр түвшний логик эзэлхүүний менежерээр хийж болно. Ийм менежерүүдтэй локал файлын системүүд өмнө нь байгаагүй (ядаж л би мэдэхгүй). Зөвхөн сүлжээний файлын системд (GlusterFS гэх мэт) ийм менежерүүд байдаг. Өөр нэг чухал жишээ бол дууны бүрэн бүтэн байдлыг шалгах хэрэгсэл (fsck) юм. Хэрэв та дэд боть тус бүрт чөлөөт блокуудын бие даасан газрын зургийг хадгалдаг бол логик эзлэхүүнийг шалгах процедурыг үр дүнтэй зэрэгцүүлж болно. Өөрөөр хэлбэл, өндөр түвшний менежерүүдтэй логик хэмжээ нь илүү сайн масштабтай байдаг.
Цаашилбал, бага түвшний эзэлхүүнтэй менежерүүд танд бүрэн хэмжээний хормын хувилбар үүсгэхийг зөвшөөрөхгүй. LVM болон ZFS-тэй төстэй файлын системүүдийн тусламжтайгаар та зөвхөн дотоод агшин зуурын зургийг авах боломжтой, харин глобал биш. Орон нутгийн агшин зуурын зургууд нь зөвхөн ердийн файлын үйлдлүүдийг нэн даруй буцаах боломжийг танд олгоно. Логик хэмжээ бүхий үйлдлүүд (төхөөрөмж нэмэх, хасах) буцаагдахгүй. Нэг жишээ авч үзье. Хэзээ нэгэн цагт 100 файл агуулсан A ба B гэсэн хоёр төхөөрөмжөөс бүрдэх логик эзлэхүүнтэй болоход та системийн S агшин зуурын зургийг аваад дараа нь өөр зуун файл үүсгэнэ.
Үүний дараа та C төхөөрөмжөө эзлэхүүндээ нэмж, эцэст нь S-ийн агшин зуурын зураг руугаа системээ буцаан шилжүүлнэ үү. Асуулт: S руу буцсаны дараа таны логик эзлэхүүн хэдэн файл, төхөөрөмж агуулсан вэ? Таны таамаглаж байсанчлан 100 файл байх болно, гэхдээ гурван төхөөрөмж байх болно - эдгээр нь A, B, C төхөөрөмжүүдтэй ижил боловч хормын хувилбарыг үүсгэх үед системд зөвхөн хоёр төхөөрөмж (A, B) байсан. С төхөөрөмж нэмэх үйлдлийг буцаагаагүй бөгөөд хэрэв та одоо C төхөөрөмжийг компьютерээс устгавал таны өгөгдлийг эвдэх болно. Тиймээс үүнийг арилгахын өмнө та эхлээд C төхөөрөмжөөс бүх өгөгдлийг А болон В төхөөрөмжүүдэд түгээх боломжтой дахин тэнцвэржүүлэлтийн тусламжтайгаар төхөөрөмжийг логик эзэлхүүнээс нь хасах үнэтэй үйлдлийг хийх шаардлагатай болно. Гэсэн хэдий ч, хэрэв таны файлын систем глобал агшин зуурын зургийг дэмждэг байсан бол ийм тэнцвэржүүлэх шаардлагагүй бөгөөд S руу шууд буцаасны дараа та C төхөөрөмжийг компьютерээс аюулгүйгээр устгаж болно.
Тиймээс, дэлхийн хэмжээний хормын хувилбаруудын гоо үзэсгэлэн нь тэдгээр нь төхөөрөмжийг их хэмжээний өгөгдөл агуулсан логик эзэлхүүнээс (мэдээжийн хэрэг, та зөв цагтаа өөрийн системийн агшин зуурын зургийг авахаа санаж байгаа бол) үнэтэй устгахаас (нэмэх) зайлсхийх боломжийг олгодог. Сануулахад, агшин зуурын зураг үүсгэх, тэдгээрт файлын системийг сэргээх нь шуурхай үйлдлүүд юм. Та гайхаж магадгүй: гурван өдөр зарцуулсан логик эзлэхүүн дээр хийсэн үйлдлийг яаж шууд буцаах боломжтой вэ? За, боломжтой! Таны файлын системийг зохих ёсоор зохион бүтээсэн тохиолдолд. Би эдгээр "3D хормын хувилбар"-ын санааг гурван жилийн өмнө гаргаж, өнгөрсөн жил энэ техникийг патентжуулсан.
Сүлжээний файлын системээс суралцах ёстой дараагийн зүйл бол сүлжээний файлын системүүд нь тусдаа машинууд дээр (мета өгөгдлийн сервер гэж нэрлэгддэг) хадгалдаг шиг мета өгөгдлийг тусдаа төхөөрөмж дээр хадгалах явдал юм. Зарим програмууд үндсэндээ мета өгөгдөлтэй ажилладаг бөгөөд эдгээр програмууд нь мета өгөгдлийг үнэтэй, өндөр хүчин чадалтай диск дээр хадгалснаар ихээхэн хурдасгах боломжтой. Файлын систем болон LVM-ийн тусламжтайгаар та тийм ч сонгомол байх боломжгүй: LVM таны өгсөн блок дотор юу байгааг мэдэхгүй (өгөгдөл эсвэл мета өгөгдөл).
Өөрийн доод түвшний LVM-ийг файлын системд хэрэгжүүлэх нь файлын систем болон LVM хослолыг илүү их нэмэгдүүлэхгүй, гэхдээ таны маш сайн хийж чадах зүйл бол файлын системийг маш ихээр эмх замбараагүй болгож, кодтой нь ажиллах боломжгүй болдог. Виртуал төхөөрөмж рүү яаран орж ирсэн ZFS болон Btrfs нь давхаргын зөрчил нь системийг архитектурын хувьд хэрхэн сүйтгэдэгийн тод жишээ юм. За, миний санаа юу вэ? Гол нь та өөрийн доод түвшний LVM-ийг файлын системд барьж болохгүй. Үүний оронд зарим сүлжээний файлын системүүд өөр өөр машинууд (хадгалах цэгүүд) ашигладаг шиг төхөөрөмжүүдийг өндөр түвшинд логик эзлэхүүн болгон нэгтгэх хэрэгтэй. Тэд муу алгоритм ашигласны улмаас үүнийг аймшигтайгаар хийдэг нь үнэн.
Үнэхээр аймшигтай алгоритмуудын жишээнд GlusterFS файлын систем дэх DHT орчуулагч болон Ceph файлын систем дэх CRUSH газрын зураг гэж нэрлэгддэг. Миний харсан алгоритмуудын аль нь ч энгийн, сайн өргөтгөх боломжтой байдлын хувьд надад таалагдаагүй. Тиймээс би алгебрээ санаж, бүх зүйлийг өөрөө зохион бүтээх хэрэгтэй болсон. 2015 онд би хэш функц дээр давхраатай болгох туршилт хийж байхдаа өөрт тохирох зүйлийг бодож олж патентжуулсан. Энэ бүхнийг амьдрал дээр хэрэгжүүлэх гэсэн оролдлого маань амжилттай болсон гэж одоо хэлж чадна. Шинэ аргын хувьд өргөтгөх чадварын асуудал надад харагдахгүй байна.
Тиймээ, дэд боть бүр санах ойд тусдаа суперблоктой төстэй бүтэц шаарддаг. Энэ үнэхээр аймшигтай гэж үү? Хэн "далайг буцалгаж", нэг орон нутгийн машин дээр хэдэн зуун мянган ба түүнээс дээш тооны төхөөрөмжүүдийн логик эзлэхүүнийг бий болгохыг би мэдэхгүй. Хэрэв хэн нэгэн надад үүнийг тайлбарлаж өгвөл би маш их талархах болно. Одоохондоо энэ бол миний хувьд зүгээр л маркетингийн тэнэглэл юм.
Цөм блокийн төхөөрөмжийн дэд системд гарсан өөрчлөлтүүд (жишээлбэл, blk-mq үүссэн) файлын системийг хэрэгжүүлэх шаардлагад хэрхэн нөлөөлсөн бэ?
Тэд ямар ч нөлөө үзүүлээгүй. Шинэ файлын системийг зохион бүтээх шаардлагатай блок давхаргад юу тохиолдохыг би мэдэхгүй. Эдгээр дэд системүүдийн хоорондын интерфейс маш муу байна. Драйвер талаасаа файлын системд үзүүлэх цорын ганц нөлөөлөл нь блокийн давхарга эхлээд дасан зохицох шинэ хөтчийн төрлүүд, дараа нь файлын систем (reiser4-ийн хувьд энэ нь шинэ залгаасуудыг нэвтрүүлэх гэсэн үг юм) байх ёстой.
Хадгалах хэрэгслийн шинэ төрлүүд (SMR эсвэл SSD-ийн өргөн хэрэглээ гэх мэт) бий болсон нь FS-ийн дизайны хувьд цоо шинэ сорилтуудыг хэлж байна уу?
Тиймээ. Эдгээр нь файлын системийг хөгжүүлэх ердийн урамшуулал юм. Бэрхшээлүүд нь янз бүрийн бөгөөд огт санаанд оромгүй байж болно. Жишээлбэл, би гаралтын гүйцэтгэл нь өгөгдлийн хэсэг болон түүний офсетийн хэмжээнээс ихээхэн хамаардаг хөтчүүдийн талаар сонссон. Файлын системийн блокийн хэмжээ нь хуудасны хэмжээнээс хэтэрч болохгүй Линукс дээр ийм диск нь анхдагч байдлаар бүрэн хүчин чадлаа харуулахгүй. Гэсэн хэдий ч, хэрэв таны файлын систем зөв зохион бүтээгдсэн бол үүнээс илүү ихийг шахах боломж бий.
Reiser4 код дээр чамаас гадна хичнээн хүн ажиллаж байна вэ?
Миний хүссэнээс бага, гэхдээ би бас нөөцийн хомсдолд ороогүй байна. Reiser4-ийн хөгжлийн хурдад би илүү их баяртай байна. Би аливаа зүйлийг яаравчлуулахаар төлөвлөөгүй - энэ бол зөв газар биш. Энд "удаан бөгөөд тогтвортой уралдаанд ялна!" Орчин үеийн файлын систем нь цөмийн хамгийн нарийн төвөгтэй дэд систем бөгөөд дизайны буруу шийдвэр нь дараагийн олон жилийн ажлыг сүйтгэж болзошгүй юм.
Сайн дурын ажилтнуудаас ямар нэг зүйлийг хэрэгжүүлэхийг хүсэхдээ тэдний хүчин чармайлт нь ноцтой зорилгоор ашиглаж болох зөв үр дүнд хүргэх болно гэдгийг би үргэлж баталгаажуулдаг. Таны ойлгож байгаагаар ийм баталгаа нь нэг дор олон байж болохгүй. Үүний зэрэгцээ ашиглах боломжгүй нь ойлгомжтой программ хангамжийн "онцлогуудыг" ичгүүр сонжуургүй сурталчилж, олон зуун хэрэглэгч, хөгжүүлэгчдийг хууран мэхэлсэн хэрнээ цөмийн дээд хэмжээний уулзалтад инээмсэглэн суугаад байгааг би тэвчиж чадахгүй.
Ямар нэгэн компани Reiser4-ийн хөгжлийг дэмжих хүсэлтэй байгаагаа илэрхийлсэн үү?
Тийм ээ, ийм саналууд, тэр дундаа томоохон борлуулагчаас ирсэн. Гэхдээ ингэхийн тулд би өөр улс руу нүүх ёстой байсан. Харамсалтай нь би одоо 30 нас хүрэхээ больсон тул зүгээр л босоод явах боломжгүй.
Reiser4-д одоо ямар онцлог дутуу байна вэ?
ReiserFS (v3) дээр байдаг шиг энгийн ботьуудын хэмжээг өөрчлөх функц байхгүй байна. DIRECT_IO тугтай файлын үйлдлүүд бас тустай байх болно. Цаашилбал, нэг эзлэхүүнийг "семантик дэд боть" болгон тусгаарлах боломжтой байх нь сайхан байх болно, тэдгээр нь тогтмол хэмжээтэй байдаггүй бөгөөд тусдаа боть болгон холбож болно. Эдгээр ажлууд нь гараа бохирдуулах гэж буй эхлэгчдэд тохиромжтой.
Эцэст нь би энгийн хэрэгжилт, удирдлага бүхий сүлжээний логик хэмжээг хармаар байна (орчин үеийн алгоритмууд үүнийг аль хэдийн зөвшөөрдөг). Reiser4-д RAID-Z, скраб, хоосон зайны кэш, 128 битийн хувьсагч болон файлын системийн зарим технологи хөгжүүлэгчдийн санаа бодол дутмаг байснаас үүссэн маркетингийн бусад утгагүй зүйлс байх нь гарцаагүй.
Шаардлагатай бүх зүйлийг залгаасуудыг ашиглан хэрэгжүүлэх боломжтой юу?
Хэрэв бид зөвхөн интерфэйсүүд болон тэдгээрийг хэрэгжүүлдэг залгаасуудын (модуль) талаар ярих юм бол энэ нь бүгд биш юм. Гэхдээ хэрэв бид эдгээр интерфэйсүүд дээр харилцаа холбоог бий болговол бусад бүх зүйлээс гадна бид илүү өндөр полиморфизмын тухай ойлголттой болох бөгөөд бид үүнийг хийж чадна. Объект хандалтат ажиллах цагийн системийг таамаглалаар царцааж, зааврын заагчийн утгыг ижил X интерфэйсийг хэрэгжүүлдэг өөр залгаас руу зааж өгөөд дараа нь системийг үргэлжлүүлэн ажиллуулахын тулд хөлдөлтөөс нь салгаж байна гэж төсөөлөөд үз дээ.
Хэрэв эцсийн хэрэглэгч энэ "орлуулалт"-ыг анзаараагүй бол бид X интерфэйс дээр систем нь тэг эрэмбийн полиморфизмтэй (эсвэл X интерфэйс дээр систем нь гетероген бөгөөд энэ нь ижил зүйл) гэж хэлнэ. Хэрэв танд одоо зөвхөн интерфэйсийн багц төдийгүй тэдгээрийн хоорондын хамаарал (интерфэйсийн график) байгаа бол та тухайн интерфейсийн "хөрш" дэх системийн нэг төрлийн бус байдлыг тодорхойлдог дээд эрэмбийн полиморфизмуудыг нэвтрүүлж болно. Би ийм ангиллыг эртнээс нэвтрүүлсэн боловч харамсалтай нь би үүнийг хэвлэх гэж хэзээ ч амжаагүй.
Тиймээс, залгаасууд болон эдгээр өндөр полиморфизмуудыг ашигласнаар та мэдэгдэж буй аливаа функцийг дүрслэхээс гадна хэзээ ч дурьдаагүй зүйлсийг "урьдчилан таамаглах" боломжтой. Би үүнийг хатуу нотолж чадаагүй ч эсрэг жишээг хараахан мэдэхгүй байна. Үнэндээ энэ асуулт надад Феликс Кляйн "Эрланген хөтөлбөр"-ийг санагдуулдаг. Тэрээр нэг удаа бүх геометрийг алгебрийн салбар (ялангуяа бүлгийн онол) болгон төлөөлөхийг оролдсон.
Одоо гол асуулт бол: Reiser4-ийг үндсэн цөм рүү дэвшүүлэх ажил хэрхэн явагдаж байна вэ? Таны сүүлчийн ярилцлагад дурдсанчлан энэ файлын системийн архитектурын талаар ямар нэгэн нийтлэл гарсан уу? Таны бодлоор энэ асуудал хэр хамааралтай вэ?
Уг нь бид үндсэн шугамд оруулахыг гурван жил гуйсан. Райзерын оруулах хүсэлтийг олон нийтийн сүлжээн дэх хамгийн сүүлд хийсэн тайлбар нь хариултгүй хэвээр үлджээ. Тиймээс нэмэлт асуултууд бидэнд тохирохгүй. Би хувьдаа бид яагаад тодорхой үйлдлийн системд "нийлэх" хэрэгтэйг ойлгохгүй байна. Линукс бол бидний хувьд цорын ганц газар биш юм. Тиймээс өөр өөр үйлдлийн системд зориулсан хэд хэдэн порттой тусдаа репозитор байдаг. Хэрэгтэй хүн бүр тохирох портоо клон хийж түүгээр хүссэн бүхнээ хийх боломжтой (мэдээж лицензийн хүрээнд). Тэгээд хэн нэгэнд хэрэггүй бол энэ миний асуудал биш. "Үүнийг Линуксийн үндсэн цөмд сурталчлах" асуудлыг үүгээр дуусгахыг би санал болгож байна.
FS архитектурын талаархи нийтлэлүүд нь хамааралтай боловч одоог хүртэл би зөвхөн өөрийн шинэ үр дүнд хүрэх цагийг олсон бөгөөд энэ нь илүү чухал гэж үздэг. Өөр нэг зүйл бол би математикч, математикийн хувьд аливаа хэвлэлд теоремуудын хураангуй, тэдгээрийн нотолгоо байдаг. Аливаа зүйлийг нотлох баримтгүйгээр нийтлэх нь муу хэлбэр гэж тооцогддог. Хэрэв би FS архитектурын талаархи зарим мэдэгдлийг хатуу нотлох юм уу үгүйсгэх юм бол үүссэн бөөгнөрөлийг даван туулахад маш хэцүү байх болно. Энэ хэнд хэрэгтэй вэ? Тийм ч учраас бүх зүйл хуучин хэлбэрээрээ буюу эх код болон түүний тайлбарууд хэвээр үлддэг байх.
Сүүлийн хэдэн жилд Reiser4-т ямар шинэ зүйл гарсан бэ?
Удаан хүлээсэн тогтвортой байдал эцэстээ биелэлээ оллоо. Хамгийн сүүлд бууж өгсөн нэг нь "устгагдах боломжгүй" лавлахуудыг үүсгэсэн алдаа байв. Асуудал нь энэ нь зөвхөн нэрний хэш мөргөлдөөний контекст болон модны зангилаа доторх тодорхой лавлах оруулгуудаар илэрч байсан явдал юм. Гэсэн хэдий ч би Reiser4-ийг үйлдвэрлэлийн зориулалтаар ашиглахыг санал болгож чадахгүй байна: энэ нь үйлдвэрлэлийн системийн администраторуудтай тодорхой хэмжээний ажил, идэвхтэй хамтын ажиллагаа шаарддаг.
Би эцэст нь олон жилийн гүйлгээний загвар болох урт хугацааны санааг хэрэгжүүлж чадсан. Өмнө нь Reiser4 зөвхөн хатуу кодлогдсон гүйлгээний загвар болох McDonald-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-ийг залгаасуудыг ашиглан сүлжээний (кластер) файлын систем болгох боломжтой юу?
Энэ нь боломжтой, тэр ч байтугай шаардлагатай! Хэрэв та зөв боловсруулсан локал файлын систем дээр суурилсан сүлжээний файлын системийг үүсгэвэл үр дүн нь үнэхээр гайхалтай байх болно! Ямар ч локал файлын систем ашиглан хэрэгждэг орчин үеийн сүлжээний файлын системийн арын хадгалах давхаргад би сэтгэл хангалуун бус байна. Энэ давхаргын оршин тогтнох нь бүрэн үндэслэлгүй юм. Сүлжээний файлын систем нь блокийн давхаргатай шууд харьцах ёстой бөгөөд локал файлын системээс нэмэлт үйлчилгээний файл үүсгэхийг шаарддаггүй!
Ерөнхийдөө файлын системийг дотоод болон сүлжээнд хуваах нь буруу нэршил юм. Энэ нь гучин жилийн өмнө хэрэглэгдэж байсан алгоритмуудын төгс бус байдлаас үүдэлтэй бөгөөд одоогоор юу ч санал болгоогүй байна. Энэ нь бас олон тооны шаардлагагүй програм хангамжийн бүрэлдэхүүн хэсгүүд (янз бүрийн үйлчилгээ гэх мэт) бий болсон шалтгаан юм. Хамгийн тохиромжтой нь цөмийн модуль болон машин бүр дээр суурилуулсан хэрэглэгчийн хэрэгслүүдийн багцаас бүрдэх ганц файлын систем байх ёстой - кластер зангилаа. Энэ файлын систем нь дотоод болон сүлжээ юм. Тэгээд өөр юу ч биш!
Хэрэв Reiser4-тэй бол LinuxХэрэв үүнээс юу ч гарахгүй бол би FreeBSD-д зориулсан FS санал болгохыг хүсч байна (өмнөх ярилцлагаас иш татсан: “...FreeBSD ... нь эрдэм шинжилгээний үндэс суурьтай... Энэ нь бид хөгжүүлэгчидтэй нийтлэг хэл олох магадлал өндөр гэсэн үг”)?
Тиймээс бид дөнгөж сая олж мэдсэнээр бид Линуксийг сайн ашиглаж байна: үүнд зориулагдсан, ажиллаж байгаа Reiser4 порт байдаг бөгөөд энэ нь манай репозиторын мастер салбарын нэг хэсэг юм. Мөн би FreeBSD-ийн талаар мартаагүй байна! Үүнийг санал болгоход чөлөөтэй! Би FreeBSD-ийн нарийн ширийнийг мэддэг хүн бүртэй нягт хамтран ажиллахад бэлэн байна. Дашрамд хэлэхэд, тэдний нийгэмлэгийн надад хамгийн их таалагддаг зүйл бол шийдвэрийг бие даасан шинжээчдийн ээлжит зөвлөл гаргадаг бөгөөд энэ нь байнгын байнгын дүр төрхтэй ямар ч холбоогүй юм.
Та хэрэглэгчийн нийгэмлэгийг хэрхэн үнэлдэг вэ? Linux өнөөдөр үү? Илүү "поп" болсон уу?
Миний ажлын чиглэлийг харгалзан үзэхэд надад үүнийг үнэлэхэд хэцүү байна. Би ихэвчлэн алдааны тайлан, хэсгийг засах хүсэлт бүхий хэрэглэгчдийг авдаг. Хэрэглэгчид нь хэрэглэгчидтэй адилхан байдаг. Зарим нь илүү ухаантай, зарим нь арай бага. Хүн болгонд тэгш ханддаг. За, хэрэв хэрэглэгч миний зааврыг үл тоомсорловол намайг уучлаарай: би ч гэсэн тэдгээрийг үл тоомсорлох болно.
Дараагийн таваас арван жилийн дотор файлын системийн хувьслыг урьдчилан таамаглах боломжтой юу? Файлын систем хөгжүүлэгчдэд тулгардаг гол бэрхшээлүүд юу гэж та бодож байна вэ?
Тийм ээ, ийм таамаглал гаргахад хэцүү биш юм. Удаан хугацааны туршид дээд талын орон зайд файлын систем хөгжөөгүй. Энэ нь зүгээр л болж байх шиг байна. Орон нутгийн файлын системийн хөгжүүлэгчид муу дизайнтай холбоотой асуудалтай тулгарч байна. Энд анхааруулга өгөх хэрэгтэй. "Хадгалах", "өнгөлсөн", зөөвөрлөх кодыг би хөгжүүлэлт гэж үзэхгүй байна. Мөн "Btrfs" хэмээх үл ойлголцлыг миний тайлбарласан шалтгааны улмаас хөгжил гэж үзэхгүй байна.
Засвар бүр зөвхөн асуудлыг улам дордуулдаг. Мөн үүнийг "ажиллуулах" ямар нэгэн "эвангелист" үргэлж байдаг. Эдгээр нь ихэвчлэн сургуулийн сурагчид, оюутнууд лекц алгасдаг. Зүгээр л төсөөлөөд үз дээ: түүний хувилбар ажилладаг, харин профессорынх тийм биш юм. Ямар их адреналин вэ! Миний бодлоор хамгийн том хор хөнөөл нь Btrfs-ийн гайхамшигт шинж чанаруудыг systemd, docker гэх мэт бүх давхаргад шургуулах гэж улайран улайрч байгаа "өөрийгөө хийдэг хүмүүс"-ээс үүдэлтэй - энэ нь аль хэдийн үсэрхийлсэн мэт харагдаж эхэлсэн.
Одоо таваас арван жилийн прогноз гаргахыг хичээцгээе. Би Reiser4 дээр бид юу хийхээ товч тайлбарласан. Дотоод файлын системийг хөгжүүлэгчдэд тулгардаг гол бэрхшээл бол (тиймээ, энэ нь аль хэдийн болсон) амьдрахын тулд зохистой ажил хийх боломжгүй байх болно. Өгөгдөл хадгалах ямар ч санаагүйгээр тэд эдгээр азгүй VFS, XFS болон ext4-ийг нөхөхийг хичээсээр байх болно. VFS-ийн нөхцөл байдал энэ арын дэвсгэр дээр ялангуяа инээдтэй харагдаж байгаа нь тогоочгүй, тогоочгүй рестораны шинэчлэлийг санагдуулдаг.
Одоо VFS код нь олон санах ойн хуудсыг нэгэн зэрэг болзолгүйгээр түгжиж, үндсэн файлын системээс тэдгээр дээр ажиллахыг хүсдэг. Үүнийг устгах үйлдлүүдийн үед Ext4-ийн гүйцэтгэлийг сайжруулах зорилгоор нэвтрүүлсэн боловч таны ойлгож байгаагаар ийм нэгэн зэрэг түгжих нь дэвшилтэт гүйлгээний загваруудтай огт нийцэхгүй байна. Энэ нь та зүгээр л цөмд ямар нэгэн төрлийн ухаалаг файлын системийн дэмжлэгийг нэмж чадахгүй гэсэн үг юм. Бусад чиглэлээр ямар байгааг би мэдэхгүй байна. LinuxГэхдээ файлын системийн тухайд энд байгаа аливаа хөгжүүлэлт нь Торвалдсын бодитоор баримталж буй бодлоготой бараг нийцэхгүй байна (академик төслүүдийг хасаж, В мод гэж юу болохыг мэдэхгүй луйварчдад төгсгөлгүй зээл олгодог). Тиймээс удаан задралын замнал тогтсон. Мэдээжийн хэрэг, тэд үүнийг "хөгжил" гэж харуулахын тулд чадах бүхнээ хийх болно.
Дараа нь файлын системийн "кастодианууд" зөвхөн хадгалах нь тийм ч үнэ цэнэтэй зүйл биш гэдгийг ойлгосноор илүү ашигтай бизнест хүчээ сорих болно. Эдгээр нь ихэвчлэн тархсан файлын систем болон виртуалчлалыг хамардаг. Магадгүй тэд загварлаг ZFS-г одоохондоо байхгүй бусад газруудад зөөвөрлөж магадгүй юм. Гэхдээ бүх дээд талын файлын системүүдийн нэгэн адил энэ нь зул сарын гацуур модтой адил юм: дээрээс нь хэд хэдэн нэмэлт бит өлгөх боломжтой ч илүү гүнзгийрч чадахгүй. ZFS-ийн тусламжтайгаар аж ахуйн нэгжийн ноцтой системийг бий болгох боломжтой гэдгийг би хүлээн зөвшөөрч байна, гэхдээ бид ирээдүйн талаар ярилцаж байгаа тул ZFS энэ талаар ямар ч найдваргүй байгааг харамсаж хэлье: виртуал төхөөрөмжөөрөө эдгээр залуус өөрсдийгөө болон хойч үеийнхээ цаашдын хөгжилд зориулж хүчилтөрөгчийг таслав. ZFS бол өчигдрийн мэдээ юм. Мөн ext4 болон XFS нь өчигдрийн өмнөх өдөр ч биш болсон.
"" гэсэн их яригдсан ойлголтыг тусад нь дурдах нь зүйтэй.Linux "Дараагийн үеийн файлын систем." Энэ бол бүрэн улс төрийн болон маркетингийн төсөл бөгөөд "файлын системийн ирээдүйг тодорхойлох" боломжтой байхаар бүтээгдсэн юм. Linux тодорхой дүрүүдийн хувьд. Гол нь өмнө нь тийм байсан Linux Өмнө нь "зүгээр л зугаа цэнгэлийн төлөө" байсан бол одоо голчлон мөнгө олох машин болсон. Юунаас ч мөнгө олдог. Жишээлбэл, сайн програм хангамжийн бүтээгдэхүүн бүтээх нь маш хэцүү боловч ухаалаг "хөгжүүлэгчид" огтхон ч ачаалал өгөх шаардлагагүй гэдгийг аль хэдийн ойлгосон: бүх төрлийн олон нийтийн арга хэмжээнд зарлагдаж, сурталчлагдсан байхгүй програм хангамжийг ч амжилттай зарж борлуулж болно - гол нь танилцуулгын слайдууд дээр олон функц байх явдал юм.
Файлын систем нь үүнд тохиромжтой, учир нь та үр дүнгээ арван жил хүлээхийг хялбархан тохиролцож чадна. Хэрэв хэн нэгэн хожим үр дүн байхгүй гэж гомдолловол тэд файлын системийг ойлгодоггүй! Энэ нь пирамид схемийг санагдуулдаг: дээд талд нь бүгдийг эхлүүлсэн луйварчид, дараа нь "ногдол ашгийг хүртдэг" азтай цөөхөн хүмүүс, өөрөөр хэлбэл, хөгжлийн санхүүжилт авч, өндөр цалинтай удирдах ажил олж, чуулганд нэрээ дуурсгах гэх мэт.
Дараа нь "азгүй" хүмүүс гарч ирнэ: тэд алдагдлаа тоолж, ашиглах боломжгүй програм хангамжийг үйлдвэрлэлд байршуулсны үр дагаврыг шийдвэрлэх гэх мэт. Тэднээс илүү олон бий. Мөн пирамидын суурь нь ашиггүй кодыг "хайчдаг" хөгжүүлэгчдийн асар том масс юм. Алдсан цагаа нөхөж чадахгүй учраас тэд хамгийн их алдагсад. Ийм пирамидууд нь Торвалдс болон түүний ойр дотны хүмүүст маш ашигтай байдаг. Мөн эдгээр пирамидууд хэдий чинээ олон байх тусам тэдэнд илүү сайн байх болно. Ийм пирамидуудыг тэжээхийн тулд цөмд юуг ч хүлээн зөвшөөрч болно. Мэдээжийн хэрэг, тэд эсрэгээрээ олон нийтэд мэдэгддэг. Гэхдээ би үгээр биш үйлдлээрээ дүгнэдэг.
Тиймээс "Линукс файлын системийн ирээдүй" нь маш их магтаал хүлээсэн боловч ашиглахад тааруухан програм хангамжийн нэг хэсэг юм. Btrfs-ийн дараа энэхүү "ирээдүй"-г Bcachefs орлох магадлал өндөр бөгөөд энэ нь эрлийзжүүлэх бас нэгэн оролдлого юм. Linux Файлын системтэй блок давхарга (муу жишээ нь халдвартай). Сонирхолтой нь энэ нь Btrfs-тэй адил асуудалтай байдаг. Би үүнийг удаан хугацаанд сэжиглэж байсан бөгөөд дараа нь кодыг харахаас татгалзаж чадаагүй - энэ бол үнэн!
Bcachefs болон Btrfs-ийн зохиогчид файлын системээ үүсгэхдээ бусад хүмүүсийн эх кодыг идэвхтэй ашиглаж, үүнийг бага зэрэг ойлгодог байв. Нөхцөл байдал нь хүүхдийн "утас" тоглоомыг маш их санагдуулдаг. Энэ кодыг цөмд хэрхэн оруулахыг би бараг төсөөлж байна. Хэн ч үнэндээ "нурууг" анзаарахгүй (хүн бүр дараа нь гишгэх болно). Кодлолын хэв маяг, байхгүй зөрчлийг буруутгах гэх мэт олон тооны маргааны дараа зохиогчийн "үнэнч байдал", бусад хөгжүүлэгчидтэй хэр сайн "харилцаж", энэ бүхнийг корпорацуудад хэр амжилттай зарж чадах талаар дүгнэлтэд хүрнэ.
Эцсийн үр дүн нь хэнийг ч сонирхохгүй. Хорин жилийн өмнө ийм байсан байж магадгүй, гэхдээ одоо өөр өөр асуултууд тавигдаж байна: ойрын арван жилийн дотор тодорхой хүмүүс ажилтай болохын тулд үүнийг хөгжүүлж чадах уу? Эцсийн үр дүнгийн талаар асуух нь харамсалтай нь хийсэн зүйл биш юм.
Ерөнхийдөө би өөрийн файлын системийг эхнээс нь зохион бүтээхгүй байхыг зөвлөж байна. Их хэмжээний санхүүгийн хөрөнгө оруулалт ч арван жилийн дотор өрсөлдөхүйц зүйлд хүрэхэд хангалтгүй. Мэдээжийн хэрэг, би цөмийн интеграцид зориулагдсан биш харин ноцтой төслүүдийн тухай ярьж байна. Тэгэхээр манайх шиг бүтээн байгуулалтын бодит хүчин чармайлтад нэгдэх нь нэрээ гаргах илүү үр дүнтэй арга юм. Энэ нь мэдээж амар биш, гэхдээ ямар ч өндөр түвшний төсөлд ийм зүйл тохиолддог.
Эхлээд та миний тавих асуудлыг шийдэх хэрэгтэй. Дараа нь таны нухацтай гэдэгт итгэлтэй байгаа тул би тусалж эхэлнэ. Уламжлал ёсоор бол бид зөвхөн өөрсдийн бүтээн байгуулалтыг ашигладаг. Үл хамаарах зүйл нь шахалтын алгоритмууд болон зарим хэш функцууд юм. Ихэнх гарааны бизнест байдаг шиг бид хөгжүүлэгчдийг бага хуралд явуулчихаад бусдын санааг нэгтгэж суудаггүй ("ямар нэгэн зүйл бүтэх байх").
Бид бүх алгоритмыг өөрсдөө боловсруулдаг. Одоогоор би өгөгдөл хадгалах шинжлэх ухааны алгебр болон комбинаторын талуудад сонирхолтой байна. Ялангуяа хязгаарлагдмал талбарууд, асимптотикууд болон тэгш бус байдал. Ердийн программистуудад ч бас ажил бий, гэхдээ би танд шууд анхааруулах ёстой: "өөр файлын систем рүү хараад адилхан хийх" гэсэн бүх саналыг үл тоомсорлох болно. Илүү нягт интеграцчилалд чиглэсэн нөхөөсүүд Linux VFS шугамаар дамжуулан.
Тиймээс, бидэнд ямар ч бэрхшээл байхгүй, гэхдээ бид хаашаа явах ёстойгоо ойлгосон бөгөөд энэ нь зөв чиглэл гэдэгт бид итгэлтэй байна. Энэ ойлголт тэнгэрээс манна шиг ирээгүй. Бидний ард 29 жилийн хөгжүүлэлтийн туршлага, эхнээс нь бичигдсэн хоёр файлын систем, өгөгдөл сэргээх олон хэрэгслүүд байгаа гэдгийг сануулъя. Мөн энэ нь маш их юм!
Эх сурвалж: opennet.ru
