Энэ хавар бид зарим танилцуулах сэдвүүдийг аль хэдийн хэлэлцсэн, жишээ нь. и . Эдгээрийн хоёр дахь нь бид ZFS-д янз бүрийн олон дискний топологийн гүйцэтгэлийг үргэлжлүүлэн судлахаа амласан. Энэ бол одоо хаа сайгүй ашиглаж байгаа дараагийн үеийн файлын систем юм нь .
За өнөөдөр ZFS-тэй танилцахад хамгийн тохиромжтой өдөр байна, сониуч уншигчид аа. OpenZFS-ийн хөгжүүлэгч Мэтт Аренсын даруухан үнэлгээгээр "энэ үнэхээр хэцүү" гэдгийг мэдэж аваарай.
Гэхдээ бид тоонууд руу орохоосоо өмнө - мөн байх болно, би амлаж байна - найман дисктэй ZFS тохиргооны бүх хувилбаруудын талаар ярих хэрэгтэй. хэрхэн Ерөнхийдөө ZFS нь өгөгдлийг дискэнд хадгалдаг.
Zpool, vdev болон төхөөрөмж
Энэхүү бүрэн сангийн диаграм нь анги тус бүрийн нэг, RAIDz2-д зориулсан дөрвөн туслах гурван vdev-г агуулдаг.
Тохироогүй vdev төрөл, хэмжээнээс бүрдэх ямар ч шалтгаан байхгүй, гэхдээ хэрэв та хүсвэл үүнийг хийхэд юу ч саад болохгүй.
ZFS файлын системийг үнэхээр ойлгохын тулд түүний бодит бүтцийг сайтар судлах хэрэгтэй. Нэгдүгээрт, ZFS нь уламжлалт эзлэхүүн болон файлын системийн удирдлагын давхаргыг нэгтгэдэг. Хоёрдугаарт, энэ нь гүйлгээний хуулбарыг бичих механизмыг ашигладаг. Эдгээр шинж чанарууд нь систем нь ердийн файлын систем болон RAID массивуудаас бүтцийн хувьд эрс ялгаатай гэсэн үг юм. Ойлгох ёстой үндсэн барилгын блокуудын эхний багц нь хадгалах сан (zpool), виртуал төхөөрөмж (vdev) болон бодит төхөөрөмж (төхөөрөмж) юм.
zpool
Zpool хадгалах сан нь ZFS-ийн хамгийн дээд бүтэц юм. Цөөрөм бүр нэг буюу хэд хэдэн виртуал төхөөрөмж агуулдаг. Хариуд нь тус бүр нь нэг буюу хэд хэдэн бодит төхөөрөмж (төхөөрөмж) агуулдаг. Виртуал усан сангууд нь бие даасан нэгжүүд юм. Нэг физик компьютер нь хоёр ба түүнээс дээш тусдаа сан агуулж болох боловч тус бүр нь бусдаас бүрэн бие даасан байдаг. Усан сан виртуал төхөөрөмжүүдийг хуваалцах боломжгүй.
ZFS илүүдэл нь усан сангийн түвшинд биш виртуал төхөөрөмжийн түвшинд байна. Пулын түвшинд ямар ч илүүдэл байхгүй—хэрэв vdev эсвэл зориулалтын vdev алдагдвал сан бүхэлдээ алдагдана.
Орчин үеийн хадгалах сангууд нь виртуал төхөөрөмжийн кэш эсвэл логоо алдах үед амьд үлдэж чадна - гэхдээ цахилгаан тасрах эсвэл системийн эвдрэлийн үед vdev бүртгэлээ алдсан тохиолдолд бага хэмжээний бохир өгөгдлийг алдаж болно.
ZFS "өгөгдлийн зурвас" нь бүхэл бүтэн санд бичигдсэн байдаг гэсэн нийтлэг буруу ойлголт байдаг. Энэ үнэн биш. Zpool бол инээдтэй RAID0 биш харин инээдтэй юм хувьсагч түгээлтийн нарийн төвөгтэй механизмтай.
Ихэнх тохиолдолд бүртгэлийг боломжтой виртуал төхөөрөмжүүдийн дунд байгаа сул зайны дагуу хуваарилдаг тул онолын хувьд бүгдийг нэгэн зэрэг бөглөх болно. ZFS-ийн сүүлийн үеийн хувилбарууд нь одоогийн vdev хэрэглээг (заялах) харгалзан үздэг - хэрэв нэг виртуал төхөөрөмж нөгөөгөөсөө хамаагүй их ачаалалтай байвал (жишээ нь, унших ачааллын улмаас) хамгийн их чөлөөт зайны харьцаатай хэдий ч үүнийг түр хугацаагаар бичихийг алгасах болно. .
Орчин үеийн ZFS бичих хуваарилалтын аргуудад суурилуулсан дахин боловсруулалтыг илрүүлэх механизм нь ер бусын өндөр ачаалалтай үед хоцролтыг бууруулж, дамжуулах чадварыг нэмэгдүүлэх боломжтой боловч тийм биш юм. carte blanche удаан HDD болон хурдан SSD-ийг нэг усан санд дур мэдэн холих. Ийм тэгш бус усан сан нь хамгийн удаан төхөөрөмжийн хурдаар ажилладаг хэвээр байх болно, өөрөөр хэлбэл энэ нь бүхэлдээ ийм төхөөрөмжөөс бүрдсэн мэт.
vdev
Хадгалах сан бүр нэг буюу хэд хэдэн виртуал төхөөрөмжөөс (vdev) бүрдэнэ. Хариуд нь vdev бүр нэг буюу хэд хэдэн бодит төхөөрөмжийг агуулдаг. Ихэнх виртуал төхөөрөмжүүдийг энгийн өгөгдөл хадгалахад ашигладаг боловч CACHE, LOG, SPECIAL зэрэг хэд хэдэн vdev туслах анги байдаг. Эдгээр vdev төрөл бүр нь нэг төхөөрөмж, RAIDz1, RAIDz2, RAIDz3 эсвэл толин тусгал гэсэн таван топологийн аль нэгтэй байж болно.
RAIDz1, RAIDz2 болон RAIDz3 нь хуучин хүмүүсийн давхар (диагональ) RAID гэж нэрлэдэг тусгай сортууд юм. 1, 2, 3 нь өгөгдлийн эгнээ тус бүрд хэдэн паритын блок хуваарилагдсаныг хэлнэ. Виртуал RAIDz төхөөрөмжүүд нь паритыг хангахын тулд тусдаа дисктэй байхын оронд дискнүүдийн хооронд паритыг хагас жигд хуваарилдаг. RAIDz массив нь паритын блоктой адил олон дискээ алдаж болно; Хэрэв энэ нь өөр нэгийг алдвал бүтэлгүйтэж, хадгалах санг авч явах болно.
Толин тусгал виртуал төхөөрөмжүүдэд (толь vdev) блок бүр нь vdev доторх төхөөрөмж бүр дээр хадгалагддаг. Хэдийгээр хоёр өргөн толин тусгал нь хамгийн түгээмэл боловч толин тусгал нь дурын тооны төхөөрөмжийг агуулж болно - том хэмжээний суулгацуудад уншлагын гүйцэтгэл болон алдааг тэсвэрлэх чадварыг сайжруулахын тулд гурвыг ихэвчлэн ашигладаг. Vdev доторх ядаж нэг төхөөрөмж ажиллаж байвал vdev толь ямар ч доголдлыг даван туулж чадна.
Ганц vdev нь угаасаа аюултай. Ийм виртуал төхөөрөмж нь нэг удаагийн эвдрэлийг даван туулахгүй бөгөөд хэрэв хадгалалт эсвэл тусгай vdev болгон ашиглавал түүний эвдрэл нь бүхэл бүтэн усан санг устгахад хүргэдэг. Энд маш болгоомжтой байгаарай.
CACHE, LOG болон SPECIAL виртуал төхөөрөмжүүдийг дээрх топологиуудын аль нэгээр нь үүсгэж болно - гэхдээ ТУСГАЙ виртуал төхөөрөмжийг алдах нь нөөцөө алддаг гэдгийг санаарай, тиймээс илүүдэл топологийг ашиглахыг зөвлөж байна.
төхөөрөмж
Энэ нь магадгүй ZFS-д ойлгоход хамгийн хялбар нэр томъёо юм - энэ нь шууд утгаараа блок санамсаргүй хандалтын төхөөрөмж юм. Виртуал төхөөрөмжүүд нь бие даасан төхөөрөмжүүдээс бүрддэг бөгөөд сан нь виртуал төхөөрөмжүүдээс бүрддэг гэдгийг санаарай.
Соронзон эсвэл хатуу төлөвт дискнүүд нь vdev-ийн барилгын блок болгон ашигладаг хамгийн түгээмэл блок төхөөрөмж юм. Гэсэн хэдий ч, /dev-д тодорхойлогчтой ямар ч төхөөрөмж үүнийг хийх болно - тиймээс бүх техник хангамжийн RAID массивыг тусдаа төхөөрөмж болгон ашиглаж болно.
Энгийн түүхий файл нь vdev-г барьж болох хамгийн чухал өөр блок төхөөрөмжүүдийн нэг юм. -аас усан сангуудыг турших Энэ нь усан сангийн командуудыг шалгах, өгөгдсөн топологийн сан эсвэл виртуал төхөөрөмжид хэр их зай байгааг харах маш тохиромжтой арга юм.
Та хэдхэн секундын дотор сийрэг файлуудаас туршилтын сан үүсгэж болно, гэхдээ дараа нь сан болон түүний бүрэлдэхүүн хэсгүүдийг бүхэлд нь устгахаа бүү мартаарай.
Та найман дисктэй сервер хүсч, 10 TB (~9300 GiB) диск ашиглахаар төлөвлөж байгаа гэж бодъё - гэхдээ аль топологи таны хэрэгцээнд хамгийн сайн тохирохыг мэдэхгүй байна. Дээрх жишээн дээр бид хэдхэн секундын дотор сийрэг файлуудаас туршилтын сан байгуулж байгаа бөгөөд 2 TB-ийн найман диск бүхий RAIDz10 vdev нь 50 TiB ашиглах хүчин чадалтай гэдгийг бид мэдэж байна.
Өөр нэг тусгай ангиллын төхөөрөмжүүд нь SPARE юм. Халуун солих төхөөрөмжүүд нь энгийн төхөөрөмжүүдээс ялгаатай нь нэг виртуал төхөөрөмж биш харин бүхэл бүтэн санд хамаардаг. Хэрэв цөөрмийн аль нэг vdev амжилтгүй болж, нөөц төхөөрөмж нь усан санд холбогдож, боломжтой бол энэ нь өртсөн vdev-д автоматаар нэгдэх болно.
Нөлөөлөлд өртсөн vdev-д холбогдсоны дараа орлуулах төхөөрөмж нь алга болсон төхөөрөмж дээр байх ёстой мэдээллийн хуулбар эсвэл сэргээн засварлаж эхэлдэг. Уламжлалт RAID-д үүнийг "дахин бүтээх" гэж нэрлэдэг бөгөөд ZFS-д үүнийг "resilvering" гэж нэрлэдэг.
Солих төхөөрөмжүүд нь бүтэлгүйтсэн төхөөрөмжүүдийг бүрмөсөн солихгүй гэдгийг анхаарах нь чухал юм. Энэ нь vdev-ийн доройтолд шаардагдах хугацааг багасгахын тулд түр зуурын орлуулалт юм. Администратор бүтэлгүйтсэн vdev төхөөрөмжийг сольсны дараа тухайн байнгын төхөөрөмжид илүүдэл нь сэргээгдэх ба SPARE нь vdev-ээс салгагдаж, бүхэл бүтэн санд зориулсан нөөц болон буцаж ирдэг.
Өгөгдлийн багц, блок, секторууд
Бидний ZFS аялалд ойлгох дараагийн барилгын блокууд нь техник хангамжтай бага холбоотой бөгөөд өгөгдлийг хэрхэн зохион байгуулж, хадгалахтай холбоотой юм. Бид ерөнхий бүтцийн талаархи ойлголтыг хадгалахын зэрэгцээ нарийн ширийн зүйлийг эмх замбараагүй болгохгүйн тулд метаслаб зэрэг хэд хэдэн давхаргыг алгасаж байна.
Өгөгдлийн багц
Бид анх өгөгдлийн багц үүсгэх үед энэ нь бүх боломжтой сан зайг харуулдаг. Дараа нь бид квотыг тогтоож, холбох цэгийг өөрчилнө. Ид шид!
Zvol нь ихэвчлэн файлын системийн давхаргаасаа хасагдсан өгөгдлийн багц бөгөөд бид үүнийг ердийн ext4 файлын системээр сольдог.
ZFS өгөгдлийн багц нь стандарт холбогдсон файлын системтэй бараг ижил байна. Энгийн файлын систем шиг энэ нь эхлээд харахад "өөр нэг хавтас" юм шиг санагддаг. Гэхдээ ердийн суулгасан файлын системүүдийн нэгэн адил ZFS өгөгдлийн багц бүр өөрийн гэсэн үндсэн шинж чанартай байдаг.
Юуны өмнө, өгөгдлийн багц нь тогтоосон квоттой байж болно. Хэрэв та суулгавал zfs set quota=100G poolname/datasetname, тэгвэл та суулгасан хавтас руу бичих боломжгүй болно /poolname/datasetname 100 ГБ-аас дээш.
Мөр бүрийн эхэнд ташуу зураас байгаа ба байхгүй байгааг анзаарсан уу? Өгөгдлийн багц бүр ZFS шатлал болон системийн холболтын шатлалд өөрийн гэсэн байр суурьтай байдаг. ZFS шатлалд тэргүүлэх налуу зураас байхгүй - та усан сангийн нэрээр эхэлж, дараа нь нэг өгөгдлийн багцаас нөгөө рүү шилжих замыг зааж өгнө. Жишээлбэл, pool/parent/child нэртэй өгөгдлийн багцын хувьд child эх өгөгдлийн багц дор parent бүтээлч нэртэй усан санд pool.
Өгөгдмөлөөр, өгөгдлийн багцын холбох цэг нь ZFS шатлал дахь түүний нэртэй тэнцүү байх бөгөөд тэргүүлэгч ташуу зураастай байх болно. pool байдлаар суурилуулсан /pool, өгөгдлийн багц parent суурилуулсан /pool/parent, мөн хүүхдийн өгөгдлийн багц child суурилуулсан /pool/parent/child. Гэхдээ өгөгдлийн багцын системийг холбох цэгийг өөрчилж болно.
Хэрэв бид зааж өгвөл zfs set mountpoint=/lol pool/parent/child, дараа нь өгөгдлийн багц pool/parent/child байдлаар системд суурилуулсан /lol.
Өгөгдлийн багцаас гадна эзлэхүүнийг (zvols) дурдах хэрэгтэй. Эзлэхүүн нь өгөгдлийн багцтай бараг ижил бөгөөд зөвхөн файлын системгүй, зүгээр л блок төхөөрөмж юм. Та жишээ нь үүсгэж болно zvol Нэртэйгээр mypool/myzvol, дараа нь ext4 файлын системээр форматлаад, дараа нь уг файлын системийг холбоно уу - одоо та ext4 файлын системтэй болсон, гэхдээ ZFS-ийн бүх хамгаалалтын функцтэй! Энэ нь нэг компьютер дээр тэнэг юм шиг санагдаж болох ч iSCSI төхөөрөмжийг экспортлоход арын хэсэг нь илүү утга учиртай юм.
Блокууд
Файлыг нэг буюу хэд хэдэн блокоор төлөөлдөг. Блок бүр нэг виртуал төхөөрөмж дээр хадгалагддаг. Блокны хэмжээ нь ихэвчлэн параметртэй тэнцүү байдаг рекорд хэмжээ, гэхдээ багасгаж болно 2^ashift, хэрэв энэ нь мета өгөгдөл эсвэл жижиг файл агуулсан бол.
Бид үнэхээр Үнэхээр Хэрэв та ээлжийг хэт бага тохируулсан бол гүйцэтгэлийн асар их торгуулийн талаар бид тоглоогүй
ZFS санд мета өгөгдөл зэрэг бүх өгөгдөл блокуудад хадгалагддаг. Өгөгдлийн багц тус бүрийн блокийн хамгийн их хэмжээг шинж чанарт тодорхойлсон recordsize (бичлэгийн хэмжээ). Бичлэгийн хэмжээ өөрчлөгдөж болох боловч энэ нь өгөгдлийн багцад аль хэдийн бичигдсэн блокуудын хэмжээ, байршлыг өөрчлөхгүй - энэ нь зөвхөн шинэ блокуудыг бичихэд л нөлөөлнө.
Өөрөөр заагаагүй бол одоогийн өгөгдмөл оруулгын хэмжээ 128 КБ байна. Гүйцэтгэл нь төгс биш, гэхдээ ихэнх тохиолдолд энэ нь аймшигтай биш байх болно, энэ нь хэцүү солилцоо юм. Recordsize 4K-ээс 1M хүртэл ямар ч утгыг тохируулах боломжтой (нэмэлт тохиргоотой recordsize Та үүнээс ч илүү суулгаж болно, гэхдээ энэ нь сайн санаа биш юм).
Аливаа блок нь зөвхөн нэг файлын өгөгдөлд хамаарах бөгөөд та хоёр өөр файлыг нэг блок болгон шахаж чадахгүй. Файл бүр хэмжээнээсээ хамааран нэг буюу хэд хэдэн блокоос бүрдэнэ. Хэрэв файлын хэмжээ нь бичлэгийн хэмжээнээс бага байвал жижиг блокт хадгалагдах болно - жишээлбэл, 2 КБ файлтай блок нь дискэн дээрх зөвхөн нэг 4 КБ секторыг эзлэх болно.
Хэрэв файл нь хэд хэдэн блок шаарддаг хангалттай том бол тухайн файлын бүх оруулгууд хэмжээтэй байх болно recordsize - гол хэсэг нь байж болох сүүлчийн оруулга багтана .
zvol боть нь өмч байхгүй recordsize - оронд нь тэд ижил төстэй өмчтэй байна volblocksize.
Салбарууд
Хамгийн сүүлчийн, хамгийн үндсэн барилгын материал бол салбар юм. Энэ нь хост төхөөрөмж рүү бичих эсвэл унших боломжтой хамгийн жижиг физик нэгж юм. Хэдэн арван жилийн турш ихэнх дискүүд 512 байт секторуудыг ашигладаг байсан. Эдгээр өдрүүдэд ихэнх хөтчүүдийг 4 киБ секторт тохируулсан бөгөөд заримыг нь ялангуяа SSD дискийг 8 киБ буюу түүнээс ч том секторт тохируулсан байна.
ZFS нь салбарын хэмжээг гараар тохируулах боломжийг олгодог онцлогтой. Энэ өмч ashift. Аshift нь хоёрын хүч юм. Жишээлбэл, ashift=9 Энэ нь салбарын хэмжээ 2^9 буюу 512 байт гэсэн үг.
ZFS нь шинэ vdev-д нэмэгдэх үед блок төхөөрөмж бүрийн талаар дэлгэрэнгүй мэдээллийг үйлдлийн системээс асууж, онолын хувьд тухайн мэдээлэлд үндэслэн ashift-ийг автоматаар тохируулдаг. Харамсалтай нь Windows XP-тэй нийцтэй байхын тулд олон хөтчүүд секторын хэмжээгээ худал хэлдэг (энэ нь бусад салбарын хэмжээтэй хөтчүүдийг ойлгох боломжгүй байсан).
Энэ нь ZFS администраторт өөрсдийн төхөөрөмжийн бодит салбарын хэмжээг мэдэж, гараар тохируулахыг зөвлөж байна гэсэн үг юм. ashift. Хэрэв ashift-ийг хэт бага тохируулсан бол унших/бичих үйлдлүүдийн тоо одон орны хэмжээгээр нэмэгддэг. Тэгэхээр 512 байт "салбарууд"-ыг жинхэнэ 4 КиБ секторт бичих нь эхний "салбар"-ыг бичиж, дараа нь 4 КиБ секторыг уншиж, хоёр дахь 512 байт "салбар"-аар өөрчлөх, шинэ рүү буцаан бичих шаардлагатай гэсэн үг юм. 4 KiB сектор гэх мэт оруулга бүрт.
Бодит амьдрал дээр ийм шийтгэл нь Samsung EVO SSD-д нөлөөлдөг бөгөөд үүнийг хэрэглэх ёстой ashift=13, гэхдээ эдгээр SSD-ууд нь салбарынхаа хэмжээгээр худлаа байдаг тул анхдагчаар тохируулсан байна ashift=9. Туршлагатай системийн администратор энэ тохиргоог өөрчлөхгүй бол энэ SSD ажиллах болно удаан ердийн соронзон HDD.
Харьцуулбал хэт том болохоор ashift торгууль бараг байхгүй. Гүйцэтгэлийн бодит цохилт байхгүй бөгөөд ашиглагдаагүй зайны хэмжээ хязгааргүй бага байна (эсвэл шахалтыг идэвхжүүлсэн бол тэг болно). Тиймээс бид 512 байт сектор ашигладаг хөтчүүдийг суулгахыг зөвлөж байна ashift=12 эсвэл бүр ashift=13ирээдүйгээ итгэлтэйгээр харах.
Хөрөнгө ashift Виртуал төхөөрөмж бүрийн vdev дээр суулгасан бөгөөд усан санд зориулагдаагүй, олон хүмүүс андуурч боддог шиг - суулгасны дараа өөрчлөгддөггүй. Хэрэв та санамсаргүйгээр цохисон бол ashift Усан санд шинэ vdev нэмэхэд та тэр бассейныг хүчин чадал муутай төхөөрөмжөөр эргэлт буцалтгүй бохирдуулсан бөгөөд дүрмээр бол бассейныг устгаад дахин эхлүүлэхээс өөр арга байхгүй. Vdev-г устгасан ч таныг эвдэрсэн тохиргооноос аврахгүй ashift!
Бичих дээр хуулбарлах механизм
Хэрэв ердийн файлын систем нь өгөгдлийг дахин бичих шаардлагатай бол тухайн блок бүрийг хаана байгаагаар нь өөрчилдөг
Бичих дээр хуулбарлах файлын систем нь блокийн шинэ хувилбарыг бичиж, хуучин хувилбарын түгжээг тайлдаг
Товчхондоо, хэрэв бид блокуудын бодит физик зохицуулалтыг үл тоомсорловол манай "өгөгдлийн сүүлт од" нь боломжтой орон зайн газрын зураг дээр зүүнээс баруун тийш хөдөлдөг "өгөгдлийн өт" болж хялбарчлах болно.
Одоо бид бичих дээр хуулбарлах агшин зуурын зургууд хэрхэн ажилладаг талаар сайн ойлголттой болох боломжтой - блок бүр олон агшин агшинд хамаарах бөгөөд холбогдох бүх агшин зуурын агшин зуурын зургийг устгах хүртэл хадгалагдах болно.
Copy on Write (CoW) механизм нь ZFS-ийг ийм гайхалтай систем болгох үндсэн суурь юм. Үндсэн ойлголт нь энгийн - хэрэв та уламжлалт файлын системээс файлыг өөрчлөхийг хүсэх юм бол энэ нь таны хүссэн зүйлийг яг таг хийх болно. Хэрэв та бичих дээр хуулбарлах файлын системээс ижил зүйл хийхийг хүсэх юм бол энэ нь "за" гэж хэлэх боловч энэ нь танд худал хэлэх болно.
Үүний оронд, бичих дээр хуулбарлах файлын систем нь өөрчилсөн блокийн шинэ хувилбарыг бичиж, дараа нь хуучин блокыг салгаж, таны саяхан бичсэн шинэ блоктой холбохын тулд файлын мета өгөгдлийг шинэчилдэг.
Хуучин блокыг салгаж, шинийг холбох нь нэг үйлдлээр хийгддэг тул үүнийг тасалдуулах боломжгүй - хэрэв та ийм зүйл болсны дараа тэжээлийг дахин тохируулбал файлын шинэ хувилбар, хэрэв та өмнө нь хүчийг дахин тохируулсан бол танд хэрэгтэй болно. хуучин хувилбар. Ямар ч тохиолдолд файлын системд зөрчил гарахгүй.
ZFS-д хуулбарлах нь зөвхөн файлын системийн түвшинд төдийгүй дискний удирдлагын түвшинд тохиолддог. Энэ нь ZFS нь бичлэг дэх хоосон зайд өртөмтгий биш гэсэн үг юм () - систем эвдрэхээс өмнө туузыг хэсэгчлэн бүртгэж, дахин ачаалсны дараа массивыг гэмтээсэн үзэгдэл. Энд зураасыг атомаар бичсэн, vdev нь үргэлж дараалсан, мөн .
ZIL: ZFS Intent Log
ZFS нь синхрон бичвэрийг тусгай аргаар зохицуулдаг - энэ нь тэдгээрийг түр зуур хадгалдаг боловч дараа нь асинхрон бичихийн хамт бүрмөсөн бичихээс өмнө шууд ZIL-д хадгалдаг.
Ерөнхийдөө ZIL-д бичсэн өгөгдлийг дахин хэзээ ч уншдаггүй. Гэхдээ энэ нь системийн эвдрэлийн дараа боломжтой юм
SLOG буюу хоёрдогч LOG төхөөрөмж нь ZIL-г үндсэн сангаас тусад нь хадгалах боломжтой тусгай бөгөөд маш хурдан ажилладаг төхөөрөмж юм.
Гэмтлийн дараа ZIL дахь бүх бохир өгөгдөл дахин тоглуулдаг - энэ тохиолдолд ZIL SLOG дээр байгаа тул үүнийг дахин тоглуулах болно.
Бичлэгийн хоёр үндсэн ангилал байдаг: синхрон (синхрон) ба асинхрон (асинхрон). Ихэнх ажлын ачааллын хувьд бичихийн дийлэнх нь асинхрон байдаг - файлын систем нь тэдгээрийг нэгтгэж, багцаар гаргах боломжийг олгодог бөгөөд энэ нь хуваагдлыг багасгаж, дамжуулах чадварыг ихээхэн нэмэгдүүлдэг.
Синхрон бичлэг бол огт өөр асуудал. Аппликешн синхрон бичих хүсэлт гаргахад файлын системд "Та үүнийг тогтворгүй санах ойд оруулах хэрэгтэй. яг одоо, тэгээд тэр болтол надад өөр хийж чадах зүйл байхгүй." Тиймээс синхрон бичгийг дискэнд нэн даруй хийх ёстой - хэрвээ энэ нь хуваагдлыг ихэсгэх эсвэл дамжуулах чадварыг бууруулдаг бол тийм байх ёстой.
ZFS нь синхрон бичвэрийг ердийн файлын системээс өөрөөр зохицуулдаг—тэдгээрийг нэн даруй ердийн хадгалалтад оруулахын оронд ZFS тэдгээрийг ZFS Intent Log буюу ZIL хэмээх тусгай хадгалах талбарт шилжүүлдэг. Гол нь эдгээр бичлэгүүд байдаг Мөн түүнчлэн санах ойд үлдэж, ердийн асинхрон бичих хүсэлтийн хамт нэгтгэгдэж, дараа нь бүрэн хэвийн TXG (гүйлгээний бүлгүүд) болгон хадгалах санд хадгалагдах болно.
Хэвийн ажиллагааны үед ZIL бичигдсэн бөгөөд дахин хэзээ ч уншихгүй. Хэдхэн хормын дараа ZIL-ийн бичлэгүүдийг RAM-аас ердийн TXG-д үндсэн хадгалалтад оруулахад тэдгээрийг ZIL-ээс салгаж авдаг. ЗИЛ-ээс ямар нэг зүйл уншдаг цорын ганц цаг бол усан санг импортлох үед юм.
Хэрэв ZIL-д өгөгдөл байгаа үед ZFS-ийн доголдол гарвал - үйлдлийн систем гацсан эсвэл цахилгаан тасарвал энэ өгөгдлийг дараагийн сан импортлох үед (жишээ нь, бүтэлгүйтлийн системийг дахин эхлүүлэх үед) унших болно. ZIL-д байгаа бүх зүйлийг уншиж, TXG-д хувааж, үндсэн дэлгүүрт хүлээлгэн өгч, импортын явцад ZIL-ээс салгах болно.
Vdev туслах ангиудын нэгийг LOG эсвэл SLOG гэдэг нь хоёрдогч LOG төхөөрөмж юм. Энэ нь нэг даалгавартай - үндсэн vdev хадгалах сан дээр ZIL хадгалахын оронд тусдаа, илүү хурдан, маш өндөр бичих эсэргүүцэлтэй, ZIL хадгалах vdev төхөөрөмжөөр усан санг хангах. ZIL нь өөрөө хадгалах байршлаас үл хамааран адилхан ажилладаг боловч LOG-тэй vdev нь маш өндөр бичих чадвартай бол синхрон бичих нь илүү хурдан байх болно.
LOG-тэй vdev-г бассейнд нэмэх нь ажиллахгүй чадахгүй байна асинхрон бичих гүйцэтгэлийг сайжруулах - та ZIL руу бүх бичихийг хүчээр хийсэн ч гэсэн zfs set sync=always, тэдгээр нь TXG-ийн үндсэн санах ойтой логгүй байхтай ижил хурдаар холбогдсон хэвээр байх болно. Гүйцэтгэлийн цорын ганц шууд сайжруулалт бол синхрон бичих хоцролт юм (илүү өндөр бүртгэлийн хурд нь үйл ажиллагааг хурдан болгодог sync).
Гэсэн хэдий ч, аль хэдийн маш их синхрон бичих шаардлагатай байгаа орчинд vdev LOG нь асинхрон бичих болон кэшгүй уншихыг шууд бусаар хурдасгах боломжтой. ZIL бүртгэлийг тусдаа vdev LOG руу буулгах нь үндсэн санах ойн IOPS-ийн зөрчил багатай гэсэн үг бөгөөд энэ нь бүх унших, бичих гүйцэтгэлийг тодорхой хэмжээгээр сайжруулдаг.
Хормын хувилбарууд
Бичих дээр хуулбарлах механизм нь ZFS-ийн атомын хормын хувилбарууд болон нэмэлт асинхрон хуулбарлахад зайлшгүй шаардлагатай суурь юм. Идэвхтэй файлын систем нь бүх оруулгуудыг одоогийн өгөгдлөөр тэмдэглэдэг заагч модтой байдаг - та агшин зуурын зургийг авахдаа энэ заагч модны хуулбарыг л хийдэг.
Идэвхтэй файлын систем дээр бичлэгийг дарж бичихэд ZFS эхлээд блокийн шинэ хувилбарыг ашиглагдаагүй зайд бичдэг. Дараа нь блокийн хуучин хувилбарыг одоогийн файлын системээс салгана. Гэхдээ зарим хормын хувилбар нь хуучин блокийг иш татсан бол энэ нь өөрчлөгдөөгүй хэвээр байна. Энэ блокийг харуулсан бүх агшин зуурын зургууд устах хүртэл хуучин блок нь үнэндээ хоосон зай болж сэргээгдэхгүй!
Хуулбарлах
2015 онд миний Steam номын сан 158 ГБ байсан бөгөөд 126 файлыг багтаасан. Энэ нь rsync-ийн оновчтой нөхцөл байдалд нэлээд ойрхон байна - сүлжээгээр ZFS хуулбарлах нь "зөвхөн" 927% хурдан байсан.
Нэг сүлжээнд 40 ГБ хэмжээтэй Windows 7 виртуал машины зургийн файлыг хуулбарлах нь огт өөр түүх юм. ZFS хуулбарлах нь rsync-ээс 289 дахин хурдан буюу хэрэв та --inplace шилжүүлэгчээр rsync-ийг дуудах хангалттай мэдлэгтэй бол "зөвхөн" 161 дахин хурдан юм.
VM дүрсийг масштаблах үед rsync нь масштабтай холбоотой асуудал үүсгэдэг. 1,9 TiB хэмжээ нь орчин үеийн VM зургийн хувьд тийм ч том биш боловч ZFS хуулбар нь rsync --inplace аргументтай байсан ч rsync-ээс 1148 дахин хурдан байхаар хангалттай том юм.
Хормын хувилбарууд хэрхэн ажилладагийг ойлгосны дараа хуулбарлахын мөн чанарыг ойлгоход хялбар байх болно. Хормын хувилбар нь зүгээр л бичлэгийн заагчийн мод учраас бид үүнийг хийвэл гэсэн үг zfs send агшин зуурын зураг, дараа нь бид энэ мод болон түүнтэй холбоотой бүх бичлэгийг илгээнэ. Бид үүнийг өнгөрөхөд zfs send в zfs receive зорилтот объект дээр блокийн бодит агуулга болон блокуудыг зорилтот өгөгдлийн багц руу иш татсан заагчийн модыг хоёуланг нь бичдэг.
Хоёр дахь удаагаа бүх зүйл илүү сонирхолтой болно zfs send. Одоо бид хоёр системтэй бөгөөд тус бүр нь poolname/datasetname@1, мөн та шинэ агшин зураг авна poolname/datasetname@2. Тиймээс, эх үүсвэрийн санд та datasetname@1 и datasetname@2, зорилтот санд зөвхөн эхний хормын хувилбар байна datasetname@1.
Учир нь эх сурвалж ба зорилтот хоёрын хооронд бид нийтлэг агшин зуурын зурагтай байдаг datasetname@1, Бид үүнийг хийж чадна нэмэгдэл zfs send дээр нь. Бид системд хэлэх үед zfs send -i poolname/datasetname@1 poolname/datasetname@2, энэ нь хоёр заагч модыг харьцуулдаг. Зөвхөн дотор байдаг аливаа заагч @2, мэдээж шинэ блокуудыг дурдаж болно - тиймээс бидэнд тэдгээр блокуудын агуулга хэрэгтэй болно.
Алсын систем дээр шат ахих замаар боловсруулалт хийдэг send яг л энгийн. Эхлээд бид урсгалд орсон бүх шинэ оруулгуудыг бичнэ send, дараа нь эдгээр блокуудад заагч нэмнэ. Voila, бидэнд байна @2 шинэ системд!
ZFS асинхрон өсөн нэмэгдэж буй хуулбар нь rsync гэх мэт өмнөх агшин зуурын бус аргуудтай харьцуулахад асар том сайжруулалт юм. Аль ч тохиолдолд зөвхөн өөрчилсөн өгөгдлийг дамжуулдаг - гэхдээ эхлээд rsync хийх ёстой уншсан нийлбэрийг шалгаж, харьцуулахын тулд хоёр талын бүх өгөгдлийг дискнээс авна. Үүний эсрэгээр, ZFS хуулбар нь заагч мод болон ерөнхий агшин зуурт дүрслэгдээгүй блокуудаас өөр зүйлийг уншдаггүй.
Баригдсан шахалт
Бичих дээр хуулбарлах механизм нь суурилуулсан шахалтын системийг хялбаршуулдаг. Уламжлалт файлын системд шахалт нь асуудалтай байдаг - өөрчлөгдсөн өгөгдлийн хуучин хувилбар болон шинэ хувилбар хоёулаа ижил зайд байна.
Хэрэв та 0x00000000 гэх мэт тэгээс мегабайтаар ажиллаж эхэлдэг файлын дунд байгаа өгөгдлийн хэсгийг авч үзвэл үүнийг дискний нэг секторт шахахад маш хялбар байдаг. Гэхдээ бид энэ мегабайт тэгийг JPEG эсвэл псевдо санамсаргүй дуу чимээ гэх мэт шахагдашгүй мегабайт өгөгдлөөр сольвол юу болох вэ? Гэнэт тэр мегабайт өгөгдөлд нэг биш, харин 256 4 КиБ сектор шаардлагатай болох ба тэр дискний зайд зөвхөн нэг сектор хадгалагдсан байна.
ZFS-д ийм асуудал гардаггүй, учир нь өөрчилсөн бичлэгүүд үргэлж ашиглагдаагүй зайд бичигддэг - анхны блок нь зөвхөн нэг 4 киб секторыг эзэлдэг, харин шинэ бичих нь 256 байх болно, гэхдээ энэ нь асуудал биш юм - саяхан өөрчилсөн фрагмент. Файлын "дунд" нь хэмжээ нь өөрчлөгдсөн эсэхээс үл хамааран ашиглагдаагүй зайд бичигдэх тул энэ нь ZFS-ийн хувьд туйлын хэвийн нөхцөл юм.
Суурилуулсан ZFS шахалтыг анхдагчаар идэвхгүй болгосон бөгөөд систем нь LZ4, gzip (1-9), LZJB болон ZLE зэрэг залгах боломжтой алгоритмуудыг санал болгодог.
- LZ4 нь маш хурдан шахах, задлах, гүйцэтгэлийн үр өгөөжийг санал болгодог урсгалын алгоритм юм, тэр ч байтугай нэлээд удаан CPU дээр ч гэсэн ихэнх хэрэглээнд зориулагдсан.
- GZIP бүх Unix хэрэглэгчдийн мэддэг, хайрладаг алдартай алгоритм юм. Үүнийг 1-р түвшинд ойртох тусам шахалтын харьцаа болон CPU-ийн хэрэглээ нэмэгдэж, шахалтын түвшин 9-9-д хэрэгжиж болно. Алгоритм нь бүх текст (эсвэл бусад өндөр шахалттай) хэрэглээний тохиолдлуудад тохиромжтой боловч ихэвчлэн CPU-д асуудал үүсгэдэг - үүнийг ашигла. болгоомжтой, ялангуяа өндөр түвшинд.
- LZJB - ZFS дахь анхны алгоритм. Энэ нь хуучирсан бөгөөд цаашид ашиглах ёсгүй, LZ4 нь бүх талаараа давуу юм.
- МУУ - тэг түвшний кодчилол, тэг түвшний кодчилол. Энэ нь ердийн өгөгдөлд огт хүрдэггүй, гэхдээ энэ нь тэгийн том дарааллыг шахдаг. Бүрэн шахагдах боломжгүй өгөгдлийн багцад (JPEG, MP4 эсвэл бусад аль хэдийн шахсан формат гэх мэт) хэрэгтэй, учир нь энэ нь шахагдах боломжгүй өгөгдлийг үл тоомсорлодог боловч үүссэн бичлэгүүдийн ашиглагдаагүй зайг шахдаг.
Бид бараг бүх хэрэглээний тохиолдолд LZ4 шахалтыг санал болгож байна; шахагдах боломжгүй өгөгдөлтэй ажиллах үед гүйцэтгэлийн шийтгэл нь маш бага бөгөөд өсөлт ердийн өгөгдлийн гүйцэтгэл нь чухал юм. Windows үйлдлийн системийг шинээр суулгахын тулд виртуал машины дүрсийг хуулж байна (шинээр суулгасан үйлдлийн систем, дотор нь өгөгдөл байхгүй) compression=lz4 -тай харьцуулахад 27%-иар хурдан давсан compression=none, in .
ARC - дасан зохицох орлуулах кэш
ZFS бол үйлдлийн системийн хуудасны кэш дээр тулгуурлан RAM-д саяхан уншсан блокуудын хуулбарыг хадгалахын оронд өөрийн унших кэш механизмыг ашигладаг орчин үеийн цорын ганц файлын систем юм.
Хэдийгээр эх кэш нь ямар ч асуудалгүй - ZFS нь шинэ санах ой хуваарилах хүсэлтэд цөм шиг хурдан хариу өгөх боломжгүй тул шинэ дуудлага malloc() санах ойн хуваарилалт нь одоогоор ARC-д байгаа RAM шаардлагатай бол амжилтгүй болно. Гэхдээ ядаж одоохондоо өөрийн кэшийг ашиглах хангалттай шалтгаан бий.
MacOS, Windows, Linux болон BSD зэрэг орчин үеийн бүх үйлдлийн системүүд нь хуудасны кэшийг хэрэгжүүлэхийн тулд LRU (Сүүлийн үед ашигласан) алгоритмыг ашигладаг. Энэ нь унших болгоны дараа кэштэй блокыг "дарааллын дээд талд" түлхэж, шаардлагатай бол шинэ кэш алдагдлыг (дискээс уншихаас илүүтэйгээр дискнээс унших ёстой блокууд) нэмэхийн тулд блокуудыг "дарааллын доод тал руу" түлхдэг энгийн алгоритм юм. кэшээс) дээд талд.
Ихэвчлэн алгоритм нь сайн ажилладаг боловч том хэмжээний өгөгдлийн багц бүхий системүүд дээр LRU нь амархан цохиж, байнга хэрэгцээтэй блокуудыг зайлуулж, кэшээс дахин хэзээ ч уншихгүй блокуудад зай гаргахад хүргэдэг.
нь "жигнэсэн" кэш гэж үзэж болох хамаагүй бага гэнэн алгоритм юм. Кэшд хадгалагдсан блокыг унших болгонд энэ нь бага зэрэг хүндэрч, нүүлгэн шилжүүлэхэд хэцүү болдог - блокыг зайлуулсны дараа ч гэсэн мөрдсөн тодорхой хугацаанд. Нүүлгэн шилжүүлсэн боловч дараа нь кэш рүү дахин унших шаардлагатай блок нь бас хүндрэх болно.
Энэ бүхний эцсийн үр дүн нь кэшийн цохилт (кэшээс уншдаг) болон алдагдсан (дискнээс уншдаг) хоорондын харьцаа илүү өндөр цохилтын харьцаатай кэш юм. Энэ бол маш чухал статистик юм - кэшийн цохилт нь өөрөө илүү хурдан засварлагдахаас гадна кэш алдагдлыг мөн хурдан засварлах боломжтой, учир нь кэш их байх тусам диск рүү параллель хүсэлт гаргах нь багасч, үлдсэн алдааны хоцролт бага байх болно. Энэ нь дискээр үйлчлэх ёстой.
дүгнэлт
Одоо бид ZFS-ийн үндсэн семантик буюу бичих дээр хуулбарлах арга хэрхэн ажилладаг, мөн хадгалах сан, виртуал төхөөрөмж, блок, сектор, файлуудын хоорондын хамаарлыг авч үзсэн болохоор бид бодит гүйцэтгэлийн талаар ярилцахад бэлэн боллоо. бодит тоо.
Дараагийн хэсэгт бид толин тусгалтай vdev болон RAIDz сангуудын бодит гүйцэтгэлийг бие биетэйгээ харьцуулж, мөн бидний судалсан уламжлалт Linux цөмийн RAID топологитой харьцуулах болно. .
Эхлээд бид зөвхөн үндсэн ойлголтуудыг - ZFS топологийг өөрсдөө авч үзэхийг хүссэн боловч дараа нь ийм Бид L2ARC, SLOG, Тусгай хуваарилалт гэх мэт туслах vdev төрлүүдийг ашиглах зэрэг ZFS-ийн илүү дэвшилтэт тохиргоо, тааруулах талаар ярихад бэлэн байх болно.
Эх сурвалж: www.habr.com