Майкрософтын шинэ ReFS файлын систем нь анх Windows 2012 дээр ажилладаг серверүүд дээр гарч ирсэн бөгөөд үүнийг зөвхөн Windows 10 -д оруулсан бөгөөд үүнийг зөвхөн дискний сангийн Хадгалах зайны нэг хэсэг болгон ашиглаж болно. Windows Server 2016 дээр Microsoft нь ReFS файлын системтэй ажиллах ажлыг ихээхэн сайжруулах болно гэж амласан бөгөөд үүнээс гадна хэвлэлд гарсан цуу ярианаас үзэхэд ReFS нь Windows 10 -ийн шинэ хувилбар дээр хуучирсан NTFS файлын системийг орлуулахаар ирсэн байж магадгүй бөгөөд үүнийг Windows гэж бахархалтайгаар нэрлэдэг. 10 Pro (дэвшилтэт компьютеруудын хувьд).
Гэхдээ ReFs гэж яг юу вэ, энэ нь одоо ашиглаж байгаа NTFS файлын системээс юугаараа ялгаатай вэ, ямар давуу талтай вэ?
Товчоор хэлбэл, энэ нь алдаанд тэсвэртэй файлын систем хэлбэрээр хийгдсэн болно. ReFS бол кодоор бүтээгдсэн шинэ файлын систем бөгөөд үндсэндээ дахин боловсруулагдсан, сайжруулсан NTFS файлын систем юм. Үүнд мэдээллийн хадгалалтын найдвартай байдлыг сайжруулах, стресс горимд тогтвортой ажиллах, файлын хэмжээ, эзлэхүүн, лавлах, эзлэхүүн, лавлах дахь файлын тоо зөвхөн 64 битийн тэмдэгтүүдийн хэмжээгээр хязгаарлагдана. Энэ хэмжээтэй хамгийн их файлын дээд хэмжээ нь 16 эксбибайт, эзлэхүүний хэмжээ нь 1 ёбибайт байх болно гэдгийг санаарай.
Одоогоор ReFS нь NTFS -ийг орлохгүй байна. Энэ нь давуу болон сул талуудтай. Гэхдээ та NTFS дээр суулгасан шиг дискийг форматлаж, Windows -ийн шинэ хуулбарыг суулгах боломжгүй гэж хэлж болно.
ReFS нь мета өгөгдлийн хяналтын дүнг ашигладаг бөгөөд өгөгдлийн файлын хяналтын дүнг ашиглаж болно. Файл унших, бичих болгондоо ReFS нь шалгалтын дүнг зөв эсэхийг шалгадаг. Энэ нь файлын систем өөрөө гэмтсэн өгөгдлийг шууд илрүүлэх чадвартай хэрэгсэлтэй гэсэн үг юм.
ReFS нь Storage Spaces -тэй нэгтгэгдсэн болно. Хэрэв та ReFS -ийн тусламжтайгаар толин тусгалыг тохируулсан бол Windows нь файлын системийн эвдрэлийг амархан илрүүлж, толин тусгалтай өгөгдлийг гэмтсэн диск рүү хуулж автоматаар засах боломжтой. Энэ функцийг Windows 10 болон Windows 8.1 -д ашиглах боломжтой.
Хэрэв ReFS эвдэрсэн өгөгдлийг илрүүлж, шаардлагатай өгөгдлийн хуулбарыг сэргээх боломжгүй бол файлын систем нь гэмтсэн өгөгдлийг дискнээс нэн даруй устгах боломжтой болно. Энэ нь NTFS -ээс ялгаатай нь системийг дахин ачаалах шаардлагагүй болно.
ReFS нь файлуудыг унших явцад тэдгээрийн бүрэн бүтэн байдлыг шалгахаас илүү их зүйлийг хийдэг. Энэ нь диск дээрх бүх файлыг тогтмол шалгаж, гэмтсэн өгөгдлийг олж тогтоох замаар өгөгдлийн бүрэн бүтэн байдлыг автоматаар шалгадаг. Энэ нь дискийг шалгахын тулд chkdsk командыг үе үе ажиллуулах шаардлагагүй болно.
Шинэ файлын систем нь бусад хэлбэрээр өгөгдлийн эвдрэлд тэсвэртэй байдаг. Жишээлбэл, та файлын мета өгөгдлийг шинэчилдэг (файлын нэр ч гэсэн). NTFS файлын систем нь файлын мета өгөгдлийг шууд өөрчилдөг. Хэрэв энэ үед системийн эвдрэл (унтраах) тохиолдвол файл гэмтэх магадлал өндөр байна. Та мета өгөгдлийг өөрчлөх үед ReFS файлын систем нь мета өгөгдлийн шинэ хуулбарыг үүсгэдэг. Файлын систем нь хуучин мета өгөгдлийг дарж бичдэггүй, харин шинэ блок дээр бичдэг. Энэ нь файлыг гэмтээх магадлалыг арилгадаг. Энэ стратегийг "хуулбарлах" гэж нэрлэдэг. Энэхүү стратеги нь Линукс дээрх ZFS, BtrFS гэх мэт бусад орчин үеийн файлын системүүд болон шинэ Apple APFS файлын систем дээр боломжтой юм.
ReFS нь NTFS -ээс илүү орчин үеийн бөгөөд илүү их хэмжээний өгөгдөл, урт файлын нэрийг дэмждэг. Энэ нь урт хугацаанд маш чухал юм.
NTFS файлын системд файлын зам 255 тэмдэгтээр хязгаарлагддаг. ReFS дээр хамгийн их тэмдэгтүүдийн тоо нь аль хэдийн гайхалтай 32,768 тэмдэгт юм. Одоогоор Windows 10 дээр NTFS -ийн тэмдэгтийн элементийг идэвхгүй болгох сонголт байдаг. Энэ хязгаарыг ReFS дискний эзлэхүүн дээр анхдагчаар идэвхгүй болгосон байдаг.
ReFS нь DOS 8.3 файлын нэрийг дэмждэггүй. NTFS боть дээр та "CProgram Files", "CProgra`1" фолдеруудад хандах боломжтой. Тэд хуучинтай нийцтэй байхын тулд шаардлагатай байдаг програм хангамж... ReFS дээр та бидний дассан фолдеруудыг олохгүй. Тэднийг арилгадаг.
NTFS -ийн дэмждэг өгөгдлийн онолын дээд хэмжээ нь 16 экзабайт, ReFS нь 262,144 экзабайт хүртэл дэмждэг. Одоо энэ тоо асар их байх шиг байна.
Хөгжүүлэгчид илүү үр ашигтай файлын системийг бий болгохыг зорьсонгүй. Тэд илүү оновчтой системийг бий болгосон.
Жишээлбэл, массивтай хамт ашиглах үед ReFS нь бодит цагийн түвшний оновчлолыг дэмждэг. Танд угсарсан хоёр дисктэй диск байдаг. Эхний дискийг өндөр хурдны хувьд сонгосон. хурдан нэвтрэхөгөгдөл рүү. Хоёр дахь дискийг урт хугацааны өгөгдөл хадгалах найдвартай байдлын шалгуураар сонгосон болно. Цаана нь ReFS нь их хэмжээний өгөгдлийг автоматаар удаан диск рүү шилжүүлж өгөгдөл хадгалах найдвартай байдлыг баталгаажуулдаг.
Windows Server 2016 дээр хөгжүүлэгчид виртуал машинуудын онцлог шинж чанарыг ашиглан гүйцэтгэлийг сайжруулах хэрэгсэл нэмсэн. Жишээлбэл, ReFS нь хуулбарлах блокуудыг дэмждэг бөгөөд энэ нь виртуал машиныг хуулах, шалгах цэгийг нэгтгэх үйл явцыг хурдасгадаг. Виртуал машины хуулбарыг үүсгэхийн тулд ReFS нь мета өгөгдлийн шинэ хуулбарыг дискэн дээр үүсгэж, диск дээрх хуулагдсан өгөгдлийн холбоосыг өгдөг. Энэ нь олон файлууд ReFS ашиглан диск дээрх ижил өгөгдлийг лавлах боломжтой болно. Виртуал машинтай ажилласны дараа өгөгдлийг өөрчилсний дараа тэдгээрийг өөр газар диск рүү бичдэг бөгөөд виртуал машины анхны мэдээлэл диск дээр үлддэг. Энэ нь хуулбар үүсгэх процессыг ихээхэн хурдасгаж, диск дээрх ачааллыг бууруулдаг.
ReFS нь "Сийрэг VDL" (ховор файлууд) дэмждэг. Нимгэн файл гэдэг нь тэг байтын дарааллыг тухайн дарааллын тухай мэдээллээр орлуулсан файл юм (нүхний жагсаалт). Нүх гэдэг нь диск дотор бичигдээгүй файл доторх тэг байтын тодорхой дараалал юм. Нүхний мэдээлэл нь өөрөө файлын системийн мета өгөгдөлд хадгалагддаг.
Сийрэг файлыг дэмжих технологи нь том файл руу тэгийг хурдан бичих боломжийг олгодог. Энэ нь шинэ, хоосон, тогтмол хэмжээтэй виртуал хатуу диск (VHD) файл үүсгэх процессыг ихээхэн хурдасгадаг. ReFS дээр ийм файл үүсгэхэд хэдхэн секунд зарцуулдаг бол NTFS дээр 10 хүртэл минут болдог.
Дээр дурдсан бүх зүйл сайхан сонсогдож байгаа ч та NTFS -ээс ReFS руу шилжих боломжгүй болно. Windows ReFS -ээс ачаалах боломжгүй тул NTFS шаарддаг.
ReFS нь NTFS -д байдаг олон технологид дутагдаж байна. Жишээлбэл, файлын системийн шахалт ба шифрлэлт, хатуу холбоосууд, өргөтгөсөн шинж чанарууд, өгөгдлийн хуулбарлах, дискний квот. Үүний зэрэгцээ, NTFS -ээс ялгаатай нь ReFS нь өгөгдлийг шифрлэх бүрэн технологийг дэмждэг - BitLocker.
Windows 10 дээр та ReFS ашиглан дискний хуваалтыг форматлах боломжгүй болно. Шинэ файлын системийг зөвхөн хадгалах системд ашиглах боломжтой бөгөөд үндсэн үүрэг нь өгөгдлийг гэмтээхээс хамгаалах явдал юм. Windows Server 2016 дээр та дискний хуваалтыг ReFS ашиглан форматлах боломжтой болно. Та үүнийг ашиглан виртуал машин ажиллуулах боломжтой болно. Гэхдээ та үүнийг ачаалах диск болгон сонгох боломжгүй болно. Windows нь зөвхөн NTFS файлын системээс ачаалагддаг.
Шинэ файлын системийг Microsoft ирээдүйд юу хүлээж байгаа нь тодорхойгүй байна. Магадгүй нэг өдөр энэ нь Windows -ийн бүх хувилбаруудад NTFS -ийг бүрэн орлох болно. Гэхдээ одоогоор ReFS -ийг зөвхөн тодорхой ажлуудад ашиглаж болно.
Шинэ үйлдлийн системийг дэмжиж олон зүйлийг хэлсэн. Давуу болон сул талыг тайлбарласан болно. Би зогсоож, нэгтгэн дүгнэхийг санал болгож байна. Энэ нь ямар зорилгоор боломжтой, магадгүй ReFS ашиглах шаардлагатай байж магадгүй юм.
Windows 10 дээр ReFS нь зөвхөн Storage Spaces -ийн бүрэлдэхүүн хэсэгтэй хамт хэрэглэгддэг. Хадгалах дискээ NTFS биш харин ReFS -ээр форматлахаа мартуузай. Энэ тохиолдолд та өгөгдөл хадгалах найдвартай байдлыг бүрэн дүүрэн үнэлэх боломжтой болно.
Windows Server дээр та ReFS -ийн хуваалтыг дискний удирдлагын консол дахь Windows -ийн стандарт хэрэгслийг ашиглан форматлах боломжтой болно. Хэрэв та виртуал сервер ашиглаж байгаа бол ReFS -ийг форматлахыг зөвлөж байна. Гэхдээ ачаалах диск нь NTFS форматтай байх ёстой гэдгийг санаарай. ReFS файлын системээс ачаалахыг Windows үйлдлийн систем дээр дэмждэггүй.
Шинэ файлын систем ReFS ба Windows 10| 2017-06-28 06:34:15 | Супер хэрэглэгч | Системийн програм хангамж | https: //site/media/system/images/new.png | Microsoft ReFS -ийн шинэ файлын систем нь хуучирсан NTFS -ийг орлуулахаар ирсэн юм. ReFS -ийн давуу талууд юу вэ, энэ нь NTFS -ээс юугаараа ялгаатай вэ? | refs, refs эсвэл ntfs, refs windows 10, refs файлын систем, шинэ файлын систем, ntfs систем, ntfs файлын систем
Ухаалаг гар утас яагаад санах ойн картаас програм ажиллуулж болохгүй гэж? Ext4 нь ext3 -аас үндсэндээ юугаараа ялгаатай вэ? FAT -ийн оронд NTFS форматтай бол флаш диск яагаад урт наслах вэ? F2FS -ийн гол асуудал юу вэ? Хариултууд нь файлын системийн бүтцийн онцлог шинж чанартай холбоотой юм. Бид тэдний тухай ярих болно.
Файлын систем нь өгөгдөл хэрхэн хадгалагдахыг тодорхойлдог. Тэд хэрэглэгч ямар хязгаарлалттай тулгарах, унших, бичих үйл ажиллагаа хэр хурдан явагдах, хөтөч ямар хугацаанд эвдрэлгүй ажиллахыг тодорхойлдог. Энэ нь ялангуяа төсвийн SSD болон түүний дүү нарын хувьд үнэн юм - флаш диск. Эдгээр онцлог шинж чанаруудыг мэддэг тул та ямар ч системийг хамгийн их хэмжээгээр шахаж, тодорхой ажлуудад ашиглахыг оновчтой болгож чадна.
Та өчүүхэн төдий зүйл хийх шаардлагагүй болгондоо файлын системийн төрөл, параметрүүдийг сонгох ёстой. Жишээлбэл, та хамгийн их тохиолддог файлын үйлдлийг хурдасгахыг хүсч байна. Файлын системийн түвшинд үүнийг хэд хэдэн аргаар хийж болно: индексжүүлэх нь хурдан хайлт хийх бөгөөд үнэгүй блокуудыг урьдчилан захиалах нь байнга өөрчлөгдөж буй файлуудыг дарж бичихэд хялбар болгоно. Мэдээллийн урьдчилсан оновчлол санамсаргүй хандалт санах ойшаардлагатай оролт гаралтын үйл ажиллагааны тоог багасгах болно.
Залхуу бичих, хуулбарлах болон бусад дэвшилтэт алгоритм гэх мэт орчин үеийн файлын системийн онцлог нь ажлын хугацааг уртасгахад тусалдаг. Эдгээр нь TLC санах ойн чип, флаш диск, санах ойн карттай хямд SSD -үүдэд онцгой хамаатай юм.
Өөр өөр түвшний дискний массивуудад тусдаа оновчлол байдаг: жишээлбэл, файлын систем нь эзлэхүүнийг офлайн горимд оруулахгүйгээр хөнгөн эзлэхүүний толин тусгал, хормын хувилбар эсвэл динамик масштабыг дэмждэг.
Хэрэглэгчид үндсэндээ үйлдлийн системийн санал болгодог файлын системтэй ажилладаг. Тэд дискний шинэ хуваалт үүсгэх нь ховор бөгөөд тохиргооныхоо талаар огт боддоггүй - тэд зүгээр л санал болгосон параметрүүдийг ашигладаг эсвэл урьдчилан форматласан медиа худалдаж авдаг.
Windows фенүүдийн хувьд бүх зүйл энгийн байдаг: бүх дискний хуваалтууд дээр NTFS, флаш диск дээрх FAT32 (эсвэл ижил NTFS). Хэрэв NAS байгаа бөгөөд бусад файлын системийг ашигладаг бол ихэнх хүмүүсийн хувьд энэ нь ойлголтгүй хэвээр үлддэг. Тэд зүгээр л сүлжээгээр холбогдож, хар хайрцгаас файл татаж авдаг.
Android үйлдлийн системтэй гар утсан дээр ext4 нь ихэвчлэн дотоод санах ой болон microSD карт дээрх FAT32 -д байдаг. Apple -ийн хувьд тэд ямар төрлийн файлын системтэй байх нь хамаагүй: HFS +, HFSX, APFS, WTFS ... тэдний хувьд зөвхөн шилдэг дизайнеруудын зурсан сайхан хавтас, файлын дүрсүүд байдаг. Linuxoids нь хамгийн баялаг сонголттой боловч та Windows болон macOS аль алинд нь үйлдлийн системд хамааралгүй файлын системийн дэмжлэгийг нэмж болно.
Зуу гаруй өөр файлын системийг бий болгосон боловч арав гаруйг нь холбогдох гэж нэрлэж болно. Тэд бүгд өөрсдийн тусгай хэрэглээнд зориулагдсан байсан ч ихэнх нь үзэл баримтлалын хувьд холбоотой болсон. Тэд ижил төрлийн танилцуулгын бүтэц (мета) өгөгдлийг ашигладаг-B мод ("хоёр мод").
Аливаа шаталсан тогтолцооны нэгэн адил В мод нь үндсэн бүртгэлээс эхэлж, цаашлаад эцсийн элементүүд рүү шилждэг - файлууд, тэдгээрийн шинж чанарууд эсвэл "навчнууд" -ын талаархи хувийн бүртгэлүүд. Ийм логик бүтцийг бий болгох гол зорилго нь хэд хэдэн терабайт эсвэл бүр илүү гайхалтай RAID массивууд гэх мэт том динамик массивууд дээр файлын системийн объектуудыг хайх ажлыг хурдасгах явдал байв.
В моднууд ижил үйлдлийг гүйцэтгэх үед бусад төрлийн В модноос хамаагүй бага дискний хандалт шаарддаг. В модны эцсийн объектууд нь ижил өндөрт шаталсан байдлаар байрладаг бөгөөд бүх үйлдлийн хурд нь модны өндөртэй пропорциональ байдагтай холбоотой юм.
Бусад тэнцвэртэй моднуудын нэгэн адил В моднууд нь үндэснээс аль ч навч хүртэлх урт замтай байдаг. Тэд өсч томрохын оронд илүү их салбарлаж, илүү өргөн ургадаг: В модны бүх салбар цэгүүд нь хүүхдийн объектын талаархи олон лавлагаа хадгалдаг тул цөөн тооны дуудлага хийхэд хялбар байдаг. Олон тооны заагч нь дурын блокуудыг унших үед толгойн байрлалыг хамгийн урт дискний үйл ажиллагааны тоог бууруулдаг.
В модны тухай ойлголтыг далаад онд боловсруулсан бөгөөд үүнээс хойш янз бүрийн сайжруулалт хийсэн. Энэ нь NTFS, BFS, XFS, JFS, ReiserFS болон олон DBMS дээр нэг хэлбэрээр хэрэгждэг. Тэд бүгд өгөгдлийн зохион байгуулалтын үндсэн зарчмын хувьд үеэлүүд юм. Ялгаа нь ихэвчлэн чухал ач холбогдолтой нарийн ширийн зүйлстэй холбоотой байдаг. Холбогдох файлын системийн сул тал нь бас нийтлэг байдаг: тэд бүгд SSD -үүд гарч ирэхээс өмнө дисктэй ажиллахаар бүтээгдсэн байдаг.
Хатуу төлөвт хөтчүүд аажмаар дискийг орлож байгаа боловч өнөөг хүртэл тэд өөрсдөд нь харь биш, өвлөгдсөн файлын системийг ашиглахаас өөр аргагүй болжээ. Эдгээр нь флаш санах ойн массив дээр суурилагдсан бөгөөд зарчмууд нь дискний төхөөрөмжүүдээс ялгаатай байдаг. Ялангуяа бичихээсээ өмнө флэш санах ойг устгах ёстой бөгөөд NAND чип дээрх энэ үйлдлийг бие даасан эсийн түвшинд гүйцэтгэх боломжгүй юм. Энэ нь зөвхөн том блокуудын хувьд бүхэлдээ боломжтой юм.
Энэ хязгаарлалт нь NAND санах ойд бүх нүдийг блок болгон нэгтгэсэн бөгөөд тэдгээр нь тус бүр хяналтын автобусанд нэг л нийтлэг холболттой байдагтай холбоотой юм. Бид пейжерийн байгууллагын нарийн ширийн зүйлийг нарийвчлан судалж, бүрэн шатлалыг зурахгүй. Нүдтэй бүлгийн үйл ажиллагааны зарчим, флаш санах ойн блокуудын хэмжээ ихэвчлэн ямар ч файлын системд оруулсан блокоос том хэмжээтэй байдаг нь чухал юм. Тиймээс NAND флаштай хөтчүүдийн бүх хаяг, тушаалыг FTL (Flash Translation Layer) хийсвэрлэлийн давхаргаар орчуулах ёстой.
Флэш санах ойн хянагч нь дискний төхөөрөмжүүдийн логиктой нийцэж, төрөлх интерфэйсийнхээ тушаалыг дэмждэг. Ихэвчлэн FTL програмыг тэдний програм хангамжид хэрэгжүүлдэг боловч энэ нь хост дээр хэсэгчлэн ажиллах боломжтой байдаг, жишээлбэл, Plextor нь бичвэрийг хурдасгадаг SSD -ийн драйверуудыг бичдэг.
Та FTL -гүйгээр хийх боломжгүй, учир нь нэг нүдэнд нэг бит бичих нь бүхэл бүтэн цуврал ажиллагааг эхлүүлэхэд хүргэдэг: хянагч шаардлагатай нүдийг агуулсан блокыг хайдаг; блокыг бүрэн уншиж, кэш эсвэл хоосон зайд бичээд дараа нь бүхэлд нь арилгаж, дараа нь шаардлагатай өөрчлөлтүүдийг буцааж бичнэ.
Энэ хандлага нь армийн өдөр тутмын амьдралтай төстэй юм: нэг цэрэгт тушаал өгөхийн тулд түрүүч ерөнхий бүрэлдэхүүн байгуулж, хөөрхий залууг дараалалгүй дуудаж, үлдсэнийг нь тараахыг тушаажээ. Одоо ховор тохиолддог NOR-санах ойд энэ байгууллага нь тусгай зориулалттай байсан: эс бүрийг бие даан хянадаг байсан (транзистор бүр тусдаа контакттай байсан).
Мэдээлэл хадгалах нягтралыг нэмэгдүүлэх, зардлыг бууруулахын тулд флаш санах ойг бий болгох тусам түүнийг үйлдвэрлэх техникийн процессыг бууруулдаг тул хянагчдын үүрэг даалгавар нэмэгдэж байна. Технологийн стандартаас гадна чипийн ашиглалтын хугацааг богиносгодог.
Нэг түвшний SLC эсүүдтэй модулиуд нь 100 мянган дахин бичих циклийн эх сурвалжтай байсан ба түүнээс дээш. Тэдний олонх нь хуучин флаш диск болон CF карт дээр ажилладаг хэвээр байна. Аж ахуйн нэгжийн ангиллын MLC (eMLC) нь нөөцийг 10-20 мянган хооронд хэлбэлздэг бол ердийн хэрэглэгчийн түвшний MLC-д 3-5 мянган гэж тооцдог. Энэ төрлийн ой санамжийг арай хямд TLC идэвхтэй шахдаг бөгөөд нөөц нь бараг мянган мөчлөгт хүрдэггүй. Флаш санах ойн ашиглалтын хугацааг зохих түвшинд байлгахын тулд програм хангамжийн тохиргоог хийх шаардлагатай бөгөөд шинэ файлын систем нь тэдгээрийн нэг болж байна.
Үйлдвэрлэгчид анх файлын системийг чухал биш гэж үзсэн. Хянагч өөрөө ямар ч төрлийн санах ойн эсүүдийн богино хугацааны массивыг хадгалах ёстой бөгөөд тэдгээрийн хоорондох ачааллыг оновчтой байдлаар хуваарилдаг. Файлын системийн драйверын хувьд энэ нь ердийн дискийг дуурайдаг бөгөөд аливаа хандалт дээр өөрөө доод түвшний оновчлол хийдэг. Гэсэн хэдий ч практик дээр оновчлол нь янз бүрийн төхөөрөмжүүдийн ид шидээс зохиомол хүртэл өөр өөр байдаг.
Байгууллагын SSD-д суурилагдсан хянагч нь жижиг компьютер юм. Энэ нь асар том санах ойн буфертай (хагас тоглолт ба түүнээс дээш) бөгөөд өгөгдөлтэй ажиллах үр ашгийг дээшлүүлэх олон аргыг дэмждэг бөгөөд энэ нь шаардлагагүй дахин бичих мөчлөгөөс зайлсхийдэг. Чип нь бүх блокуудыг кэш дотор байрлуулдаг, залхуутай бичдэг, хуулбарыг шууд дамжуулдаг, зарим блокыг нөөцөлж, бусдыг цаана нь цэвэрлэдэг. Энэ бүх ид шид нь OS, програмууд болон хэрэглэгчид огт анзаарагддаггүй. Ийм SSD -тэй бол ямар файлын систем ашиглах нь хамаагүй. Дотоод оновчлол нь гүйцэтгэл, нөөцөд гадныхаас хамаагүй илүү нөлөө үзүүлдэг.
Төсвийн SSDs (тэр ч байтугай флаш дискүүд) нь арай бага ухаалаг хянагчаар тоноглогдсон байдаг. Тэдгээрийн кэш нь таслагдсан эсвэл байхгүй бөгөөд дэвшилтэт серверийн технологийг огт ашигладаггүй. Санах ойн картуудад хянагч нь маш энгийн байдаг тул тэдгээрийг огт байдаггүй гэж байнга хэлдэг. Тиймээс, флаш санах ойтой хямд төхөөрөмжүүдийн хувьд гадаад ачааллыг тэнцвэржүүлэх арга нь хамааралтай хэвээр байгаа бөгөөд голчлон тусгай файлын системийг ашигладаг.
Флэш санах ойн зохион байгуулалтын зарчмуудыг харгалзан файлын систем бичих анхны оролдлогуудын нэг бол JFFS - Journaling Flash File System юм. Эхэндээ Шведийн Axis Communications компанийн энэхүү бүтээн байгуулалт нь Axis -ийн ерээд онд үйлдвэрлэсэн сүлжээний төхөөрөмжүүдийн санах ойн үр ашгийг дээшлүүлэхэд чиглэсэн байв. JFFS -ийн эхний хувилбар нь зөвхөн NOR санах ойг дэмждэг байсан бол хоёр дахь хувилбарт NAND -тай найзууд болсон.
JFFS2 нь одоогоор хязгаарлагдмал хэрэглээтэй байна. Ихэнхдээ үүнийг суулгагдсан системд зориулсан Linux түгээлтэд ашигладаг хэвээр байна. Үүнийг чиглүүлэгч, IP камер, NAS болон бусад зүйлсийн интернетээс олж болно. Ерөнхийдөө хаана ч хамаагүй бага хэмжээний найдвартай санах ой шаардлагатай байдаг.
JFFS2 -ийн цаашдын хөгжлийн хүчин чармайлт бол инодыг тусдаа файлд хадгалсан LogFS байв. Энэхүү санааг зохиогчид бол IBM -ийн Германы хэлтсийн ажилтан Жорн Энгель, Оснабрюкийн их сургуулийн профессор Роберт Мертенс юм. LogFS -ийн эх кодыг GitHub дээрээс авах боломжтой. Хамгийн сүүлийн өөрчлөлтийг дөрвөн жилийн өмнө хийсэн гэж үзвэл LogFS нь олонд танигдаагүй байна.
Гэхдээ эдгээр оролдлогууд нь өөр нэг тусгай файлын систем болох F2FS -ийг бий болгоход түлхэц болсон юм. Үүнийг Samsung корпораци боловсруулсан бөгөөд энэ нь дэлхий даяар үйлдвэрлэсэн флаш санах ойн ихээхэн хэсгийг эзэлдэг. Samsung нь NAND Flash чипийг өөрийн төхөөрөмж болон бусад компаниудад зориулан үйлдвэрлэдэг бөгөөд хуучин дискний оронд цоо шинэ интерфэйстэй SSD -ийг хөгжүүлж байна. Флаш санах ойг оновчтой болгосон тусгай файлын системийг бий болгох нь Samsung -ийн үүднээс авч үзвэл эрт дээр үеэс зайлшгүй шаардлагатай болсон.
Дөрвөн жилийн өмнө, 2012 онд Samsung F2FS (Flash Friendly File System) -ийг бүтээсэн. Түүний санаа нь сайн боловч хэрэгжилт нь чийгтэй болсон. F2FS -ийг үүсгэх гол ажил нь энгийн байсан: нүдийг дахин бичих үйл ажиллагааны тоог бууруулж, ачааллыг аль болох жигд хуваарилах. Энэ нь нэг блок доторх хэд хэдэн нүдтэй нэгэн зэрэг үйлдэл хийх шаардлагатай бөгөөд нэг нэгээр нь хүчиндэхгүй байх шаардлагатай. Энэ нь бидэнд OS -ийн анхны хүсэлтээр одоо байгаа блокуудыг шууд дахин бичих шаардлагагүй, харин тушаал, өгөгдлийг кэш хийх, хоосон зайд шинэ блок нэмж оруулах, эсийг устгах ажлыг хойшлуулах шаардлагатай гэсэн үг юм.
Өнөөдөр F2FS -ийн дэмжлэгийг албан ёсоор Линукс дээр (мөн Android дээр) хэрэгжүүлж байгаа боловч практик дээр ямар нэгэн онцгой давуу тал хараахан гаргаагүй байна. Энэхүү файлын системийн гол онцлог (хойшлуулсан дарж бичих) нь түүний үр дүнтэй байдлын талаар эрт дүгнэлт хийхэд хүргэсэн. Хуучин кэш хийх заль мэх нь жишиг үнэлгээний анхны хувилбарыг хүртэл хуурч мэхэлсэн бөгөөд F2FS нь давуу талаа хэдхэн хувиар (хүлээгдэж байснаар), бүр хэд хэдэн удаа биш, харин хэмжээний дарааллаар харуулсан байдаг. Зүгээр л F2FS драйвер нь хянагчийн хийхээр төлөвлөж байсан үйлдлийн талаар мэдээлсэн болно. Гэсэн хэдий ч хэрэв F2FS -ийн бодит гүйцэтгэл нь бага байвал эсийн элэгдэл нь ижил ext4 -ийг ашиглахтай харьцуулахад бага байх болно. Хямд хянагчийн хийж чадахгүй байгаа оновчлолыг файлын системийн түвшинд хийх болно.
F2FS -ийг геексүүдийн хувьд чамин гэж үздэг. Самсунгийн өөрийн гэсэн ухаалаг гар утас хүртэл ext4 ашигладаг. Олон хүмүүс үүнийг ext3 -ийн цаашдын хөгжил гэж үздэг боловч энэ нь огт үнэн биш юм. Энэ нь нэг файлын 2 TB -ийн саадыг эвдэж, бусад хэмжигдэхүүнүүдийг нэмэгдүүлэхээс илүү хувьсгал юм.
Компьютер том, файлууд жижиг байхад хаяглахад хялбар байсан. Файл бүрт тодорхой тооны блок хуваарилагдсан бөгөөд тэдгээрийн хаягийг захидал харилцааны хүснэгтэд оруулсан болно. Ext3 файлын систем ингэж ажилласан бөгөөд өнөөг хүртэл ашиглагдаж байна. Гэхдээ ext4 дээр хаяглах өөр өөр арга гарч ирэв.
Хамрах хүрээг inode өргөтгөлүүд гэж бүхэлд нь холбосон дараалсан блокуудын салангид багц гэж ойлгож болно. Нэг хэмжээгээр бүхэл бүтэн дунд хэмжээтэй файл агуулж болох бөгөөд том файлуудын хувьд арваас хоёр хүрээг хуваарилахад хангалттай. Энэ нь дөрвөн килобайт хэмжээтэй хэдэн зуун мянган жижиг блокуудыг шийдвэрлэхээс хамаагүй илүү үр дүнтэй юм.
Бичих механизм өөрөө ext4 дээр өөрчлөгдсөн. Одоо блокуудын хуваарилалт нэг хүсэлтээр шууд хийгддэг. Урьдчилан биш, харин диск рүү өгөгдөл бичихийн өмнөхөн. Олон блокны хуваарилалтыг хойшлуулсан нь ext3 нүгэл үйлдсэн шаардлагагүй үйлдлүүдээс ангижрах боломжийг танд олгоно: үүнд шинэ файлын блокуудыг кэшт бүрэн багтаасан байсан ч түр зуур устгахаар төлөвлөсөн байсан ч тэр даруй хуваарилсан болно.
Тэнцвэртэй мод, тэдгээрийн өөрчлөлтөөс гадна бусад алдартай логик бүтэц бий. Үндсэндээ өөр төрлийн зохион байгуулалттай файлын системүүд байдаг, жишээлбэл шугаман. Та дор хаяж нэгийг нь маш их ашигладаг байх.
Тааварыг тааварла: арван хоёр настайдаа тэрээр таргалж эхлэв, арван зургаан настайдаа тэр тэнэг тарган эмэгтэй, гучин хоёр настайдаа тарган болж, энгийн хүн хэвээр байв. Тэр эмэгтэй хэн бэ?
Зөв, энэ бол FAT файлын системийн тухай түүх юм. Тохиромжтой байдлын шаардлага нь түүнд муу удамшил өгсөн. Уян диск дээр энэ нь 12 бит, хатуу диск дээр анх 16 бит байсан бөгөөд өнөөдрийг хүртэл 32 бит болж буурсан байна. Дараагийн хувилбар бүрт хаяглах блокуудын тоо нэмэгдсэн боловч үндсэндээ юу ч өөрчлөгдөөгүй.
Одоог хүртэл түгээмэл хэвээр байгаа FAT32 файлын систем хорин жилийн өмнө гарч ирсэн. Өнөөдөр энэ нь энгийн хэвээр байгаа бөгөөд ACL, дискний квот, дэвсгэр шахалт болон бусад орчин үеийн өгөгдлийн оновчлолын технологийг дэмждэггүй.
Өнөөдөр FAT32 яагаад хэрэгтэй байна вэ? Зөвхөн нийцтэй байхын тулд бүгд адилхан. Үйлдвэрлэгчид ямар ч OS нь FAT32 хуваалтыг унших боломжтой гэдэгт итгэдэг. Тиймээс тэд үүнийг гадаад хатуу диск, USB флаш болон санах ойн карт дээр бүтээдэг.
Ухаалаг гар утсанд хэрэглэгддэг MicroSD (HC) картууд нь анхдагчаар FAT32 форматтай байдаг. Энэ нь тэдгээрт програм суулгах, дотоод санах ойгоос өгөгдөл дамжуулахад тулгардаг гол бэрхшээл юм. Үүнийг даван туулахын тулд та карт дээр ext3 эсвэл ext4 хуваалт үүсгэх хэрэгтэй. Файлын бүх шинж чанаруудыг (эзэмшигч болон хандалтын эрхийг оруулаад) түүнд шилжүүлэх боломжтой тул аливаа програм дотоод санах ойгоос эхлүүлсэн мэт ажиллах боломжтой.
Windows нь флаш диск дээр нэгээс илүү хуваалт үүсгэж чадахгүй, гэхдээ үүний тулд та Linux (дор хаяж виртуал машинд) эсвэл логик хуваалтуудтай ажиллах дэвшилтэт хэрэгслийг ажиллуулж болно, жишээлбэл, MiniTool Partition Wizard Free. Картанд ext3 / ext4 -тэй нэмэлт анхан шатны хуваалтыг олсны дараа Link2SD програм болон үүнтэй төстэй програмууд нь ганц FAT32 хуваалттай харьцуулахад илүү олон сонголтыг санал болгоно.
FAT32 -ийг дэмжсэн өөр нэг аргумент бол тэмдэглэл хөтлөхгүй байх явдал бөгөөд энэ нь бичих үйлдлийг хурдан хийх, NAND Flash санах ойн эсийн элэгдэл багатай гэсэн үг юм. Практик дээр FAT32 -ийг ашиглах нь эсрэгээрээ хүргэж, өөр олон асуудал үүсгэдэг.
Флаш диск болон санах ойн картууд хурдан үхдэг, учир нь FAT32 -ийн аливаа өөрчлөлт нь файлын хүснэгтийн хоёр сүлжээ байрладаг ижил салбаруудыг дарж бичихэд хүргэдэг. Би вэб хуудсыг бүхэлд нь хадгалсан бөгөөд үүнийг хэдэн зуун удаа дахин бичсэн бөгөөд флаш диск дээр өөр жижиг GIF нэмж оруулав. Зөөврийн програм хангамжийг эхлүүлсэн үү? Тэрээр түр зуурын файл үүсгэж, ажлын явцад байнга өөрчилж байдаг. Тиймээс алдаанд тэсвэртэй $ MFT хүснэгт бүхий NTFS-ийг флаш диск дээр ашиглах нь илүү дээр юм. Жижиг файлуудыг үндсэн файлын хүснэгтэд шууд хадгалах боломжтой бөгөөд түүний өргөтгөл, хуулбарыг флаш санах ойн өөр өөр хэсэгт бичдэг. Нэмж дурдахад NTFS индексжүүлэлт нь хайлтыг илүү хурдан болгодог.
Ихэнх хэрэглэгчид тулгардаг бас нэг асуудал бол 4 ГБ -аас дээш хэмжээтэй файлыг FAT32 хуваалт руу бичих боломжгүй байдаг. Үүний шалтгаан нь FAT32 -д файлын хэмжээг файл хуваарилах хүснэгтэд 32 битээр дүрсэлсэн бөгөөд 2 ^ 32 (хасах нэг, хасах нь) ердөө дөрвөн тоглолтыг өгдөг. Шинээр худалдаж авсан флаш диск дээр ердийн чанартай кино, DVD дүрсийг бичих боломжгүй юм.
Том файл хуулах нь асуудлын тал хувь хэвээр байгаа: хэрэв та үүнийг хийхийг оролдвол алдаа нь дор хаяж шууд харагдана. Бусад тохиолдолд FAT32 нь цагийн бөмбөг болж ажилладаг. Жишээлбэл, та зөөврийн програмыг USB флаш диск рүү хуулж, эхлээд үүнийг ямар ч асуудалгүйгээр ашиглаж болно. Удаан хугацааны дараа програмуудын нэг (жишээлбэл, нягтлан бодох бүртгэл эсвэл имэйл) мэдээллийн сан дүүрч, ... шинэчлэгдэхээ болино. 4 ГБ -ын хязгаарт хүрсэн тул файлыг дарж бичих боломжгүй.
Илүү ойлгомжтой асуудал бол FAT32 дээр файл эсвэл директор үүсгэх огноог хоёр секундын нарийвчлалтай зааж өгөх явдал юм. Энэ нь цагийн тэмдгийг ашигладаг олон криптограф програмуудад хангалтгүй юм. Огноо шинж чанарын нарийвчлал багатай байгаа нь аюулгүй байдлын үүднээс FAT32 -ийг бүрэн файлын систем гэж үзэхгүй байгаагийн бас нэг шалтгаан юм. Гэсэн хэдий ч түүний сул талыг өөрийн хэрэгцээнд ашиглаж болно. Жишээлбэл, хэрэв та ямар нэгэн файлыг NTFS хуваалтаас FAT32 эзлэхүүн рүү хуулж авбал тэдгээр нь бүх мета өгөгдөл, түүнчлэн удамшсан болон тусгайлан тохируулсан зөвшөөрлүүдээс цэвэрлэгдэх болно. FAT нь тэднийг дэмждэггүй.
FAT12 / 16/32 -ээс ялгаатай нь exFAT нь USB Flash болон том санах ойн картуудад (≥ 32 ГБ) зориулагдсан болно. Өргөтгөсөн FAT нь дээр дурдсан FAT32 -ийн сул талыг арилгаж, аливаа өөрчлөлт дээр нэг салбарыг дарж бичдэг. 64 битийн системийн хувьд энэ нь бараг нэг файлын хэмжээтэй утга учиртай хязгаарлалтгүй байдаг. Онолын хувьд энэ нь 2 ^ 64 байт (16 EB) урттай байж болох бөгөөд ийм хэмжээтэй карт удахгүй гарч ирэхгүй.
ExFAT -ийн өөр нэг том ялгаа нь Хандалтыг хянах жагсаалт (ACLs) -ийг дэмждэг явдал юм. Энэ бол ерээд оны үеийн энгийн зүйл биш боловч хаалттай формат нь exFAT -ийг хэрэгжүүлэхэд саад болж байна. ExFAT дэмжлэгийг зөвхөн Windows (XP SP2 -ээс эхлэн) болон OS X (10.6.5 -с эхлэн) дээр бүрэн, хууль ёсны дагуу хэрэгжүүлдэг. Линукс болон * BSD дээр үүнийг хязгаарлалттай эсвэл хууль ёсны дагуу дэмждэггүй. Майкрософт нь exFAT -ийг ашиглахын тулд тусгай зөвшөөрөл шаарддаг бөгөөд энэ чиглэлээр хууль эрх зүйн олон маргаан гардаг.
B модны файлын системийн бас нэг тод жишээ бол Btrfs юм. Энэхүү FS нь 2007 онд гарч ирсэн бөгөөд анх SSD болон RAID -тэй ажиллах зорилгоор Oracle -д бүтээгдсэн. Жишээлбэл, амьд систем дээр шинэ инодыг үүсгэх, эсвэл эзлэхүүнийг хоосон зай гаргахгүйгээр эзлэхүүнийг дэд боть болгон хуваах замаар динамикаар өргөжүүлж болно.
Btrfs дээр хэрэгжүүлсэн хуулбарлах механизм, Device mapper цөмийн модульд бүрэн нэгтгэх нь виртуал блок төхөөрөмжөөр дамжуулан бараг агшин зуурын агшин зуур зураг авах боломжийг олгодог. Өгөгдлийг урьдчилан шахах (zlib эсвэл lzo) болон дахин хуулбарлах нь флаш санах ойн ашиглалтын хугацааг уртасгахын зэрэгцээ үндсэн үйл ажиллагааг хурдасгадаг. Энэ нь өгөгдлийн сан (шахалтыг 2-4 удаа хийдэг) ба жижиг файлууд (тэдгээрийг дараалсан том блокоор бичсэн бөгөөд "навч" дээр шууд хадгалах боломжтой) дээр ажиллахад онцгой ажиглагддаг.
Btrfs нь бүрэн тэмдэглэл хөтлөх (өгөгдөл, мета өгөгдөл), эзлэхүүнийг салгахгүйгээр шалгах, орчин үеийн бусад олон боломжуудыг дэмждэг. Btrfs кодыг GPL лицензийн дагуу нийтэлдэг. Энэхүү файлын систем нь цөм 4.3.1 -ээс хойш Линукс дээр тогтвортой ажиллаж байна.
Бараг бүх орчин үеийн файлын системүүд (ext3 / ext4, NTFS, HFSX, Btrfs болон бусад) нь бүртгэлд орсон хүмүүсийн ерөнхий бүлэгт багтдаг, учир нь тэд хийсэн өөрчлөлтийн бүртгэлийг тусдаа бүртгэлд (журнал) хөтөлж, үүнийг шалгадаг. дискний ажиллагааны явцад алдаа гарсан тохиолдолд ... Гэсэн хэдий ч эдгээр файлын системийн үг хэллэг, алдаанд тэсвэртэй байдлын түвшин өөр байна.
Ext3 нь бүртгэлийн гурван горимыг дэмждэг: давталт, дараалсан, бүрэн бүртгэл. Эхний горим нь өгөгдөлд гарсан өөрчлөлтийн хувьд асинхрон байдлаар хийгддэг зөвхөн ерөнхий өөрчлөлтийг (мета өгөгдөл) бүртгэхийг хэлнэ. Хоёрдахь горимд ижил мета өгөгдлийн бичлэгийг хийдэг боловч ямар нэгэн өөрчлөлт хийхээс өмнө хийдэг. Гурав дахь горим нь бүрэн бүртгэлтэй тэнцүү (мета өгөгдөл болон файлууд хоёуланд нь өөрчлөгддөг).
Зөвхөн сүүлийн сонголт нь өгөгдлийн бүрэн бүтэн байдлыг баталгаажуулдаг. Нөгөө хоёр нь шалгах явцад гарсан алдааг олж тогтоох ажлыг хурдасгаж, файлын системийн бүрэн бүтэн байдлыг сэргээх баталгаа болдог боловч файлын агуулгыг баталгаажуулдаггүй.
NTFS бүртгэл нь ext3 -ийн хоёр дахь бүртгэлийн горимтой төстэй юм. Зөвхөн мета өгөгдлийн өөрчлөлтийг бүртгэлд бүртгэдэг бөгөөд алдаа гарсан тохиолдолд өгөгдөл өөрөө алдагдаж магадгүй юм. Энэхүү NTFS тэмдэглэлийн аргыг найдвартай байдлыг дээд зэргээр хангах арга гэж үзээгүй бөгөөд зөвхөн гүйцэтгэл ба алдааны хүлцэл хоёрын хоорондох арилжаа юм. Бүртгэлийн бүрэн системтэй ажиллахад дассан хүмүүс NTFS-ийг хуурамч сэтгүүл гэж үздэг.
NTFS хандлага нь ext3 -ийн үндсэн хувилбараас арай дээр юм. NTFS -д өмнө нь хүлээгдэж буй дискний бүх үйлдлийг дуусгахын тулд хяналтын цэгүүдийг үе үе бий болгодог. Хяналтын цэгүүд нь \ System Volume Infromation \ дахь сэргээх цэгүүдтэй ямар ч холбоогүй юм. Эдгээр нь бүртгэлийн зөвхөн нэмэлт оруулгууд юм.
Дадлагаас үзэхэд NTFS-ийн ийм хэсэгчилсэн тэмдэглэл нь ихэнх тохиолдолд асуудалгүй ажиллахад хангалттай байдаг. Эцсийн эцэст, цахилгаан тасарсан ч гэсэн дискний төхөөрөмжүүд тэр даруй хүчээ алддаггүй. Цахилгаан хангамжийн хэсэг ба хөтчүүд дэх олон тооны конденсаторууд нь өөрөө бичих үйлдлийг дуусгахад хангалттай энергийн хамгийн бага нөөцийг өгдөг. Орчин үеийн SSD нь хурд, хэмнэлттэй тул ихэвчлэн хүлээгдэж буй үйлдлийг гүйцэтгэх хангалттай энергитэй байдаг. Бүрэн бүртгэлд шилжих оролдлого нь ихэнх үйл ажиллагааны хурдыг хэд дахин бууруулах болно.
Файлын системийн ашиглалт нь OS түвшний дэмжлэгээр хязгаарлагддаг. Жишээлбэл, Windows нь ext2 / 3/4 болон HFS +-г ойлгодоггүй боловч заримдаа тэдгээрийг ашиглах шаардлагатай болдог. Үүнийг тохирох драйверыг нэмж хийж болно.
Хэсэгчилсэн ext4 дэмжлэгтэй ext2 / 3 хуваалтыг унших, бичих драйверийг нээнэ үү. Хамгийн сүүлийн хувилбар нь 16 TB хүртэлх багтаамж, хуваалтыг дэмждэг. LVM, ACL болон өргөтгөсөн шинж чанаруудыг дэмждэггүй.
Total Commander -д зориулсан үнэгүй залгаас байдаг. Ext2 / 3/4 хуваалтыг уншихыг дэмждэг.
coLinux бол Linux цөмийн нээлттэй эх сурвалж, үнэгүй порт юм. 32 битийн драйверын тусламжтайгаар виртуалчлалын технологийг ашиглахгүйгээр Linux 2000-ийг Windows 7-7 дээр ажиллуулах боломжийг танд олгоно. Зөвхөн 32 битийн хувилбарыг дэмждэг. 64 битийн өөрчлөлтийг боловсруулах ажлыг цуцлав. coLinux нь бусад зүйлсээс гадна Windows -ээс ext2 / 3/4 хуваалтуудад хандах хандалтыг зохион байгуулах боломжийг олгодог. Төслийн дэмжлэгийг 2014 онд зогсоосон.
Windows 10 нь Линуксд зориулагдсан файлын системийн анхны дэмжлэгтэй байж магадгүй бөгөөд энэ нь зүгээр л нуугдсан байдаг. Эдгээр бодлыг цөмийн түвшний драйвер Lxcore.sys болон Svchost.exe процессоор номын сан болгон ачаалдаг LxssManager үйлчилгээ санал болгодог. Энэ талаар илүү ихийг мэдэхийн тулд Алекс Ионескугийн Black Hat 2016 дээр танилцуулсан "Windows 10 дотор нуугдсан Linux цөм" илтгэлийг үзнэ үү.
Windows -д зориулсан ExtFS бол Paragon -ийн гаргасан төлбөртэй драйвер юм. Энэ нь Windows 7-10 дээр ажилладаг, ext2 / 3/4 боть руу унших / бичих хандалтыг дэмждэг. Windows дээр ext4 бараг бүрэн дэмждэг.
Windows 10 -д зориулсан HFS + бол Paragon Software -ийн өөр нэг жолооч юм. Нэрийг нь үл харгалзан XP -ээс эхлэн Windows -ийн бүх хувилбарт ажилладаг. Аливаа хуваалт (MBR / GPT) бүхий дискэн дээрх HFS + / HFSX файлын системд бүрэн нэвтрэх боломжийг олгодог.
WinBtrfs бол Windows -д зориулсан Btrfs драйверын анхны хувилбар юм. 0.6 хувилбар дээр аль хэдийн Btrfs боть руу унших, бичих хандалтыг дэмждэг. Хатуу ба бэлгэдлийн холбоосыг зохицуулж чаддаг, өгөгдлийн өөр урсгал, ACL, хоёр төрлийн шахалт, асинхрон унших / бичих горимыг дэмждэг. Одоогоор WinBtrfs энэ файлын системийг хадгалахын тулд mkfs.btrfs, btrfs-balance болон бусад хэрэгслүүдийг ашиглаж чадахгүй байна.
| Файлын систем | Mac-si-mal-ny эзлэхүүний хэмжээ | Нэг файлын урьдчилсан хэмжээ | Урт файлын нэрээр | Файлын бүтэн нэрний урт (root -ээс авсан замыг оруулаад) | Файл ба / эсвэл каталогийг урьдчилан устгах | Файл / каталогийн огноог зааж өгөх нарийвчлал | Дос-ту-па эрх | Хатуу холбоосууд | Sim-үнэгүй холбоосууд | Гэнэтийн зураг авалт | Өгөгдлийг цаана нь шахаж байна | Цаана байгаа өгөгдлийг шифрлэх | Өгөгдлийн өвөө-pli-ka-tion |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FAT16 | 512 байтын салбарт 2 ГБ эсвэл 64 КБ кластерт 4 ГБ | 2 ГБ | LFN -тэй 255 байт | - | - | - | - | - | - | - | - | - | - |
| FAT32 | 2 KB салбарт 8 сүрьеэ | 4 ГБ (2 ^ 32 - 1 байт) | LFN -тэй 255 байт | CDS бүхий 32 дэд директор хүртэл | 65460 | 10ms (үүсгэх) / 2s (өөрчлөх) | Үгүй | Үгүй | Үгүй | Үгүй | Үгүй | Үгүй | Үгүй |
| exFAT | ≈ Гуравдагч талын хязгаарлалтын улмаас 128 PB (2 ^ 25-1 байтын 2 ^ 32-1 кластер) онолын хувьд / 512 TB | 16 ГЗ (2 ^ 64 - 1 байт) | 2796202 каталогид байна | 10 ms | ACL | Үгүй | Үгүй | Үгүй | Үгүй | Үгүй | Үгүй | ||
| NTFS | 64 KB кластерт 256 TB эсвэл 4K кластерт 16 TB | 16 TB (Win 7) / 256 TB (Win 8) | 255 Юникод тэмдэгт (UTF-16) | Юникодын 32,760 тэмдэгт, гэхдээ нэг элементэд 255 тэмдэгтээс хэтрэхгүй байна | 2^32-1 | 100 н | ACL | Тийм ээ | Тийм ээ | Тийм ээ | Тийм ээ | Тийм ээ | Тийм ээ |
| HFS + | 8 ГЗ (2 ^ 63 байт) | 8 ЕБ | 255 Юникод тэмдэгт (UTF-16) | тус тусад нь хязгаарлаагүй | 2^32-1 | 1 сек | Unix, ACL | Тийм ээ | Тийм ээ | Үгүй | Тийм ээ | Тийм ээ | Үгүй |
| APFS | 8 ГЗ (2 ^ 63 байт) | 8 ЕБ | 255 Юникод тэмдэгт (UTF-16) | тус тусад нь хязгаарлаагүй | 2^63 | 1 ns | Unix, ACL | Тийм ээ | Тийм ээ | Тийм ээ | Тийм ээ | Тийм ээ | Тийм ээ |
| Ext3 | 32 TB (онолын) / 4K кластерт 16 TB (e2fs програмын хязгаарлалтын улмаас) | Хуучин програмуудын хувьд 2 TB (онолын) / 16 GB | 255 Юникод тэмдэгт (UTF-16) | тус тусад нь хязгаарлаагүй | - | 1 сек | Unix, ACL | Тийм ээ | Тийм ээ | Үгүй | Үгүй | Үгүй | Үгүй |
| Ext4 | 1 EB (онолын) / 4K кластерт 16 TB (e2fs програмын хязгаарлагдмал байдлаас шалтгаалан) | 16 сүрьеэ | 255 Юникод тэмдэгт (UTF-16) | тус тусад нь хязгаарлаагүй | 4 тэрбум | 1 ns | POSIX | Тийм ээ | Тийм ээ | Үгүй | Үгүй | Тийм ээ | Үгүй |
| F2FS | 16 сүрьеэ | 3.94 сүрьеэ | 255 байт | тус тусад нь хязгаарлаагүй | - | 1 ns | POSIX ACL | Тийм ээ | Тийм ээ | Үгүй | Үгүй | Тийм ээ | Үгүй |
| BTRFS | 16 ГЗ (2 ^ 64 - 1 байт) | 16 ЕБ | 255 ASCII тэмдэгт | 2 ^ 17 байт | - | 1 ns | POSIX ACL | Тийм ээ | Тийм ээ | Тийм ээ | Тийм ээ | Тийм ээ | Тийм ээ |
Би үүнийг блог дээрээ нэг удаа зарласан боловч энэ талаар юу ч мэдэгдэхгүй байсан бөгөөд одоо шинээр хийгдсэн ReFS -тэй богино боловч илүү тогтвортой танилцах цаг болжээ.
Гэсэн хэдий ч бүх зүйл хязгаартай бөгөөд файлын системийн боломжууд ч бас байдаг. Өнөөдөр NTFS -ийн боломжууд хязгаарлагдмал байна: их хэмжээний хадгалах хэрэгслийг шалгах нь хэтэрхий удаан үргэлжилдэг, "Журнал" нь хандалтыг удаашруулж, файлын дээд хэмжээнд бараг хүрсэн байна. Үүнийг ойлгосон Майкрософт Windows 8 дээр шинэ файлын систем - ReFS (Resilient File System) -ийг нэвтрүүлсэн. ReFS нь том, хурдан хатуу дискний өгөгдөл хамгаалалтыг хамгийн сайн хангадаг гэж үздэг. Мэдээжийн хэрэг энэ нь бас сул талуудтай боловч Windows 8 дээр үнэхээр асар их хэрэглээ эхлэхээс өмнө тэдний талаар ярих нь хэцүү байдаг.
Тиймээс одоо ReFS -ийн дотоод шинж чанар, давуу талыг ойлгохыг хичээцгээе.
ReFS нь анх "Протогон" гэсэн нэртэй байжээ. Жилийн өмнө түүний тухай олон нийтэд анх удаа хэлсэн Стивен Синофский- Microsoft -ийн Windows -ийн хэлтсийн ерөнхийлөгч, Windows -ийн хөгжил, маркетингийг хариуцдаг Internet Explorer.
Тэрээр эдгээр үгээр хэлэв:
“NTFS бол өнөө үед хамгийн өргөн хэрэглэгддэг, дэвшилтэт, баялаг файлын систем юм. Гэхдээ Windows -ийг дахин эргэцүүлэн бодож, бид одоогоор Windows 8 -ийг боловсруулж байгаа ч үүгээр зогсохгүй. Тиймээс, Windows 8 -ийн хамт бид цоо шинэ файлын системийг нэвтрүүлж байна. ReFS нь NTFS дээр суурилагдсан тул дараагийн үеийн хадгалах технологи, хувилбаруудын хэрэгцээг хангах зорилгоор зохион бүтээгдэж, инженерчлэгдсэн бөгөөд энэ нь харилцан уялдаатай байдлыг хадгалдаг.
Windows 8 дээр ReFS -ийг зөвхөн Windows Server 8 -ийн нэг хэсэг болгон нэвтрүүлэх болно, энэ нь өмнөх бүх файлын системийг хэрэгжүүлэхэд ашигладаг байсан арга юм. Мэдээжийн хэрэг, хэрэглээний түвшинд үйлчлүүлэгчид NTFS өгөгдөлтэй адилаар ReFS өгөгдөлд хандах эрхийг өгөх болно. NTFS нь PC файлын системийн салбарт тэргүүлэгч технологи хэвээр байгааг санаарай. ”
Үнэндээ бид ReFS -ийг Windows Server 8 сервер үйлдлийн систем дээр анх харсан. Шинэ файлын системийг эхнээс нь боловсруулаагүй болно. Жишээлбэл, ReFS нь файлуудыг нээх, хаах, унших, бичихдээ NTFS -тэй ижил API ашигладаг. Түүнчлэн, олон танил шинж чанарууд NTFS -ээс шилжсэн - жишээлбэл диск шифрлэлт Bitlockerба бэлгэдлийн холбоосуудномын сангийн хувьд. Гэхдээ энэ нь алга болсон, жишээлбэл. өгөгдлийн шахалтболон бусад олон функцууд.
ReFS -ийн гол шинэчлэл нь файл, хавтасны бүтцийг бий болгох, удирдахад чиглэгддэг. Тэдний даалгавар бол алдааг автоматаар засах, хамгийн их масштаблах, үргэлж онлайн горимд ажиллуулах явдал юм.
ReFS бүтцийн дискний хэрэгжилт нь бусад Microsoft файлын системээс эрс ялгаатай юм. Майкрософт хөгжүүлэгчид ReFS-ийн мэдээллийн баазаас сайн мэддэг B-tree концепцийг хэрэгжүүлснээр санаагаа хэрэгжүүлэх боломжтой болсон. Файлын систем дэх фолдерууд нь оруулга хэлбэрээр файл бүхий хүснэгт хэлбэрээр бүтэцлэгдсэн байдаг. Эдгээр нь эргээд дэд хүснэгт болгон нэмсэн тодорхой шинж чанаруудыг хүлээн авч, шаталсан модны бүтцийг бий болгодог. Дискний хоосон зайг хүртэл хүснэгт хэлбэрээр зохион байгуулдаг.
Системийн бүх элементүүдийн жинхэнэ 64 битийн дугаарлалттай зэрэгцэн цаашид масштаблах явцад "бөглөрөл" гарч ирэхгүй болно.
Үүний үр дүнд ReFS системийн цөм нь объектын хүснэгт юм - систем дээрх бүх хүснэгтийг жагсаасан төв лавлах. Энэхүү аргын чухал давуу тал нь: ReFS нь бүртгэлийн нарийн төвөгтэй менежментээс татгалзаж, шинэ файлын мэдээллийг хоосон зайнд оруулах үүрэг хүлээдэг бөгөөд энэ нь түүнийг дахин бичихээс сэргийлдэг.
« Навчны каталог"Бичсэн оруулгууд байна. Фолдерын объектын үндсэн гурван төрлийн бүртгэл байдаг: лавлах тодорхойлогч, индексийн бүртгэл, үүрлэсэн объектын тодорхойлогч. Ийм бүх бүртгэлийг хавтас танигчтай тусдаа B ± мод хэлбэрээр савладаг; Энэ модны үндэс нь "Каталог" модны B ± навч бөгөөд бараг бүх тооны бичлэгийг хавтсанд баглах боломжийг олгодог. Доод түвшинд, хавтасны модны B ± хуудсан дээр үндсэндээ хавтасны талаарх үндсэн өгөгдөл (нэр, "стандарт мэдээлэл", файлын нэрний шинж чанар гэх мэт) агуулсан лавлах тайлбарлагч бичлэг байдаг.
Цаашид каталогид байрлуулсан болно индекс бичлэгүүд: хавтас доторх зүйлсийн талаархи мэдээллийг агуулсан богино бүтэц. Эдгээр бичлэгүүд нь NTFS -ээс хамаагүй богино бөгөөд энэ нь эзлэхүүн дэх мета өгөгдлийн хэт ачаалал багатай юм.
Төгсгөлд нь каталогийн оруулгууд байна. Фолдеруудын хувьд эдгээр элементүүд нь багцын нэр, "Каталог" дахь хавтасны таних тэмдэг, "стандарт мэдээлэл" -ийн бүтцийг агуулдаг. Файлуудын хувьд танигч байдаггүй - үүний оронд бүтэц нь файлын үндсэн модны B ± root гэх мэт файлын талаархи бүх үндсэн мэдээллийг агуулдаг. Үүний дагуу файл нь бараг бүх тооны фрагментээс бүрдэж болно.
NTFS -ийн нэгэн адил ReFS нь файлын мэдээлэл (мета өгөгдөл) болон файлын агуулга (хэрэглэгчийн өгөгдөл) -ийг үндсэндээ ялгадаг. Гэсэн хэдий ч хамгаалалтын функцийг хоёуланд нь ижил байдлаар өгдөг. Мета өгөгдлийг хяналтын дүнгээр анхдагчаар хамгаалдаг - хэрэглэгчийн өгөгдөлд ижил хамгаалалтыг (хэрэв хүсвэл) өгч болно. Эдгээр шалгалтын дүнг диск дээр бие биенээсээ аюулгүй зайд байрлуулсан байдаг тул алдаа гарсан тохиолдолд өгөгдлийг сэргээх нь илүү хялбар болно.
Хоосон файлын системийн мета өгөгдлийн хэмжээ нь файлын системийн хэмжээнээс 0.1% орчим байдаг (өөрөөр хэлбэл 2 TB эзлэхүүн тутамд ойролцоогоор 2 GB). Зарим үндсэн мета өгөгдлүүд нь ослын уян хатан байдлыг сайжруулахын тулд давхардсан байдаг
Бидний олж харсан ReFS хувилбар Windows Server 8 бета хувилбар, зөвхөн 64КБ өгөгдлийн кластер, 16КБ мета өгөгдлийн кластерыг дэмждэг. Одоогоор ReFS эзлэхүүнийг үүсгэх үед "Cluster Size" параметрийг үл тоомсорлож, үргэлж анхдагч гэж үздэг. Файлын системийг форматлахдаа 64 КБ нь кластерын хэмжээтэй цорын ганц боломжтой сонголт юм.
Энэхүү кластерын хэмжээ нь ямар ч хэмжээтэй файлын системийг зохион байгуулахад хангалттай гэдгийг бид хүлээн зөвшөөрч байна. Гаж нөлөө нь өгөгдөл хадгалалтын мэдэгдэхүйц илүүдэл юм (диск дээрх 1 байтын файл нь 64 КБ-ын бүрэн блокыг эзэлдэг).
Файлын системийн архитектурын хувьд ReFS нь тоног төхөөрөмжийн томоохон эвдрэлийн дараа ч гэсэн файлуудыг аюулгүй сэргээхэд шаардлагатай бүх хэрэгслүүдтэй байдаг. NTFS файлын системийн бүртгэлийн системийн гол сул тал бол дискийг шинэчлэх нь бичлэг хийх явцад цахилгаан тасарсан тохиолдолд урьд нь бүртгэгдсэн мета өгөгдлийг гэмтээж болзошгүй юм.Энэ нөлөө нь тогтвортой нэртэй болсон. " унжсан бичлэг».
Урьдчилан сэргийлэх өлгөөтэй бичлэгүүд, Майкрософт мета өгөгдлийн бүтцийн хэсэг нь өөрийн таниулагчийг агуулсан шинэ арга барилыг авсан бөгөөд энэ нь бүтцийн өмчлөлийг шалгах боломжийг танд олгоно; мета өгөгдлийн холбоосууд нь иш татсан блокуудын 64 битийн хяналтын дүнг агуулдаг.
Мета өгөгдлийн бүтцэд гарсан аливаа өөрчлөлт хоёр үе шаттайгаар явагддаг. Нэгдүгээрт, мета өгөгдлийн шинэ (өөрчилсөн) хуулбарыг чөлөөт дискний зайд бүтээдэг бөгөөд үүний дараа амжилттай болсон тохиолдолд атомын шинэчлэлтийн ажиллагаа нь холбоосыг хуучин (өөрчлөгдөөгүй) мета өгөгдлийн талбар руу шилжүүлдэг. Энд өгөгдлийн бүрэн бүтэн байдлыг автоматаар хадгалах замаар бүртгэл хийх шаардлагагүй болно.
Гэсэн хэдий ч тайлбарласан схем нь хэрэглэгчийн өгөгдөлд хамаарахгүй тул файлын агуулгад гарсан аливаа өөрчлөлтийг шууд файл дээр бичнэ. Метадата бүтцийг сэргээн босгосноор файл устгагдах бөгөөд энэ нь мета өгөгдлийн блокийн өмнөх хувилбарыг диск дээр хадгалдаг. Энэ арга нь устгасан файлуудыг шинэ хэрэглэгчийн өгөгдөл дээр дарж бичих хүртэл сэргээх боломжийг танд олгоно.
Тусдаа сэдэв бол диск гэмтсэн тохиолдолд ReFS эвдрэлийг тэсвэрлэх явдал юм. Систем нь дискний эвдрэл гэмтлийн бүх хэлбэр, түүний дотор бичлэгийн хаяг алдагдсан, буруу газарт хадгалагдсан гэх мэтийг тодорхойлох боломжтой. бага зэрэг ялзрах(хэвлэл мэдээллийн хэрэгслийн мэдээллийн доройтол)
"Integral Streams" сонголтыг идэвхжүүлсэн үед ReFS нь файлуудын агуулгыг шалгах нийлбэрээс шалгадаг бөгөөд гуравдагч талын байршилд байгаа файлуудын өөрчлөлтийг үргэлж бичдэг. Энэ нь урьд өмнө байсан өгөгдлийг дарж бичихэд алдагдахгүй гэсэн баталгааг өгдөг. Өгөгдөл бичих үед хяналтын дүнг автоматаар шинэчилдэг тул хэрэв бичих амжилтгүй болвол хэрэглэгч шалгах файлын хувилбартай болно.
ReFS -ийн аюулгүй байдлын өөр нэг сонирхолтой сэдэв бол харьцах явдал юм Хадгалах зай... ReFS ба Хадгалах зайнэг хадгалах системийн хоёр бүрэлдэхүүн хэсэг болгон бие биенээ нөхөх зориулалттай. Гүйцэтгэлийг сайжруулахаас гадна Хадгалах зайОлон диск дээр хуулбарыг хадгалах замаар өгөгдлийг хэсэгчилсэн болон бүрэн эвдрэлээс хамгаалах. Унших явцад алдаа гардаг Хадгалах зайтэд хуулбарыг уншиж чаддаг бөгөөд бичих алдаа гарсан тохиолдолд (унших / бичих явцад хэвлэл мэдээллийн өгөгдөл бүрэн алдагдсан байсан ч) өгөгдлийг "ил тод" дахин хуваарилах боломжтой байдаг. Дадлагаас харахад ихэнх тохиолдолд ийм алдаа нь зөөвөрлөгчтэй ямар ч холбоогүй байдаг - энэ нь өгөгдлийн авлига, өгөгдөл алдагдсан эсвэл буруу газарт хадгалагдсанаас болдог.
Эдгээр нь ReFS -ийн хяналтын дүнг ашиглан илрүүлж болох алдаа юм. Алдаа гарсан тохиолдолд ReFS холбоо барина Хадгалах займэдээллийн бүх боломжит хуулбарыг уншихын тулд, мөн хяналтын дүнг үндэслэн зөв хуулбарыг сонгоно. Дараа нь систем өгдөг Хадгалах зайжинхэнэ хуулбар дээр үндэслэн гэмтсэн хуулбарыг сэргээх тушаал. Энэ бүхэн нь хэрэглээний үүднээс ил тод явагддаг.
Microsoft -ийн вэбсайтад дурдсанчлан Windows Server 8, хяналтын дүнг ReFS мета өгөгдөлд үргэлж идэвхжүүлдэг бөгөөд эзлэхүүнийг толинд тусгасан гэж үзнэ Хадгалах зай, автомат залруулга бас идэвхжсэн байна. Бүх уялдаатай урсгалыг ижил аргаар хамгаалдаг. Энэ нь хэрэглэгчийн хувьд бүрэн бүтэн байдлын өндөр түвшний шийдлийг бий болгодог бөгөөд үүгээр дамжуулан харьцангуй найдваргүй хадгалалтыг маш найдвартай болгож чаддаг.
Дээр дурдсан бүрэн бүтэн байдлын урсгал нь файлын агуулгыг бүх төрлийн өгөгдлийн эвдрэлээс хамгаалдаг. Гэсэн хэдий ч энэ шинж чанарыг зарим тохиолдолд ашиглах боломжгүй байдаг.
Жишээлбэл, зарим програмууд дискэн дээр ямар нэгэн файл эрэмбэлэх замаар цэвэр файл хадгалах менежментийг илүүд үздэг. Уялдаа холбоотой урсгалууд нь файлын агуулга өөрчлөгдөх бүрт блокуудыг дахин хуваарилдаг тул файлуудын зохион байгуулалтыг эдгээр аппликешнүүдэд хэт урьдчилан тааварлах боломжгүй байдаг. Өгөгдлийн сангийн систем нь үүний тод жишээ юм. Дүрмээр бол ийм програмууд нь файлын агуулгын хяналтын дүнг бие даан хянадаг бөгөөд API -тай шууд харьцах замаар өгөгдлийг шалгах, засах чадвартай байдаг.
Дискний эвдрэл, хадгалалтын эвдрэл гарсан тохиолдолд ReFS хэрхэн ажилладаг нь ойлгомжтой гэж бодож байна. ". бага зэрэг ялзрах"Дискний ховор уншдаг хэсгүүдэд гэмтэл илрээгүй тохиолдолд хурдан өсч эхэлдэг. Ийм эвдрэлийг уншиж, илрүүлэх үед энэ нь аль хэдийн хуулбаруудад нөлөөлж магадгүй эсвэл бусад алдаанаас болж өгөгдөл алдагдах болно.
Үйл явцыг даван туулахын тулд бага зэрэг ялзрах, Microsoft нь толин тусгал хадгалах санд байгаа ReFS эзлэхүүн дэх тогтмол урсгалаас мета өгөгдөл, өгөгдлийг үе үе цэвэрлэдэг үндсэн системийн даалгаврыг нэмж оруулав. Цэвэрлэгээг бүх илүүдэл хуулбарыг уншиж, зөв эсэхийг ReFS -ийн хяналтын дүнг ашиглан шалгаж болно. Хэрэв хяналтын дүн нийлдэггүй бол алдаатай хуулбарыг сайн хуулбараар засдаг.
Уламжлал ёсоор "sysadmin -ийн хар дарсан зүүд" гэж нэрлэж болох аюул занал байсаар байна. Толин тусгалтай орон зайн эзэлхүүн хүртэл гэмтэх тохиолдол ховор байдаг. Жишээлбэл, бүтэлгүйтсэн системийн санах ой нь өгөгдлийг гэмтээж, улмаар диск дээр хадгалагдаж, илүүдэл хуулбарыг гэмтээж болно. Нэмж дурдахад олон хэрэглэгчид ReFS -ийн толин тусгал хадгалах зайг ашиглахгүй байхаар шийдэж магадгүй юм.
Ийм тохиолдолд эзлэхүүн гэмтэх үед ReFS нь "засварлах" функцийг гүйцэтгэдэг бөгөөд энэ нь ажлын эзлэхүүн дэх нэрийн талбараас өгөгдлийг устгах функц юм. Түүний эрхэм зорилго бол зөв өгөгдөлд нөлөөлж болзошгүй нөхөж баршгүй хохирлоос урьдчилан сэргийлэх явдал юм. Жишээлбэл, хэрэв директор доторх ганц файл эвдэрч, автоматаар засах боломжгүй бол ReFS нь тухайн файлыг системийн системийн нэрийн талбараас устгаж, эзлэхүүний үлдсэн хэсгийг сэргээнэ.
Файлын систем нь гэмтсэн файлыг нээж, устгаж чадахгүй бөгөөд администратор энэ талаар юу ч хийж чадахгүйд бид дассан.
Гэхдээ ReFS нь эвдэрсэн өгөгдлийг сэргээж чаддаг тул администратор энэ файлыг нөөцлөлтөөс сэргээх эсвэл системийг хаахаас зайлсхийж програмыг дахин үүсгэх боломжтой. Энэ нь хэрэглэгч эсвэл администратор баталгаажуулах, засварлах процедурыг офлайнаар хийх шаардлагагүй болсон гэсэн үг юм. Серверүүдийн хувьд энэ нь гэмтсэний улмаас батерейны ашиглалтын хугацаа урт байх эрсдэлгүйгээр их хэмжээний өгөгдлийг байршуулах боломжийг олгодог.
Мэдээжийн хэрэг, Windows 8 -тэй компьютерууд өргөн тархаж, тэдэнтэй дор хаяж зургаан сар идэвхтэй ажилласны дараа л ReFS -ийн практик байдал, тав тухыг (эсвэл эсрэг талын чанарыг) үнэлэх боломжтой. Энэ хооронд G8 -ийн боломжит хэрэглэгчид хариултаас илүү олон асуулт байна.
Жишээлбэл, энэ нь: Windows 8 дээр NTFS -ээс өгөгдлийг ReFS рүү хялбар, хялбархан хөрвүүлэх боломжтой юу? Майкрософт хэлэхдээ форматыг хөрвүүлэх функц хүлээгдээгүй байгаа ч мэдээллийг хуулж болно. ReFS -ийн хамрах хүрээ нь тодорхой байна: эхлээд үүнийг зөвхөн серверийн том өгөгдлийн менежер болгон ашиглах боломжтой (үнэндээ үүнийг аль хэдийн ашиглаж байсан). ReFS -тэй гадаад диск байхгүй болно - зөвхөн дотоод хөтчүүд. Мэдээжийн хэрэг, цаг хугацаа өнгөрөхөд ReFS нь илүү олон функцээр тоноглогдсон бөгөөд хуучин системийг орлох боломжтой болно.
Майкрософт хэлэхдээ энэ нь Windows 8 -д зориулсан анхны үйлчилгээний багцыг гаргаснаар тохиолдох болно.
Майкрософт ReFS -ийг туршсан гэж мэдэгдэж байна.
"Хорь гаруй жилийн турш NTFS -д зориулж бичсэн олон арван мянган туршилтуудын цогц, өргөн хүрээний багцыг ашиглан. Эдгээр туршилтууд нь системд тулгарч болзошгүй, тухайлбал, цахилгаан тасарсан үед, өргөтгөх чадвар, гүйцэтгэлтэй холбоотой асуудлуудтай тулгарч болзошгүй байршуулах нөхцөлийг дахин бий болгодог. Тиймээс бид ReFS систем нь хяналттай орчинд туршилтыг явуулахад бэлэн болсон гэж хэлж болно. "
Гэхдээ үүнтэй зэрэгцэн хөгжүүлэгчид том файлын системийн анхны хувилбар болохын хувьд ReFS -тэй харьцахдаа болгоомжтой байхыг шаардаж магадгүй юм.
"Бид Windows 8 -д зориулсан ReFS -ийг бета хувилбар гэж тодорхойлдоггүй. Шинэ файлын систем нь Windows 8 бета хувилбараас гарахад бэлэн болно, учир нь өгөгдлийн найдвартай байдлаас илүү чухал зүйл байхгүй. Тиймээс системийн бусад талаас ялгаатай нь энэ нь анхны хэрэглээ, туршилтанд консерватив хандлагыг шаарддаг. "
Олон талаараа ийм учраас ReFS -ийг үе шаттай төлөвлөгөөний дагуу ашиглах болно. Эхлээд Windows Server -ийн хадгалалтын систем, дараа нь хэрэглэгчдэд зориулсан хадгалах сан, эцэст нь ачаалах эзлэхүүн болгон ашиглах болно. Гэсэн хэдий ч ижил төстэй "болгоомжтой хандлага" -ыг өмнө нь шинэ файлын систем гаргахад ашиглаж байсан.
Энэ нийтлэлд бид үүнийг ойлгох болно ReFS нь ямар онцлог шинж чанартай байдаг ба энэ нь NTFS файлын системээс юугаараа илүү вэ?... ReFS дискний зайнаас өгөгдлийг хэрхэн яаж сэргээх вэ. Майкрософтын шинэ ReFS файлын системийг анх Windows Server 2012 дээр танилцуулсан. Энэ нь Windows 10 -д Дискний зайны хэрэгслийн нэг хэсэг юм. ReFS -ийг дискний санд ашиглах боломжтой. Windows Server 2016 -ийг гаргаснаар файлын систем сайжирсан бөгөөд удахгүй Windows 10 -ийн шинэ хувилбар дээр гарах болно.
ReFS нь ямар онцлог шинж чанартай байдаг бөгөөд энэ нь одоогийн NTFS системээс юугаараа илүү вэ?
Агуулга:Гэсэн товчлол Уян хатан файлын систем ReFS бол NTFS дээр суурилсан шинэ систем юм. Энэ үе шатанд ReFS нь гэрийн хэрэглэгчдэд зориулсан NTFS -ийн иж бүрэн орлуулалтыг санал болгодоггүй. Файлын систем нь давуу болон сул талуудтай.
ReFS нь NTFS -ийн үндсэн асуудлыг шийдвэрлэхэд зориулагдсан болно. Энэ нь өгөгдлийн авлигад илүү тэсвэртэй, ачааллыг нэмэгдүүлж, маш том файлын системийг хялбархан хуваарилдаг. Энэ юу гэсэн үг болохыг харцгаая?
Файлын систем нь мета өгөгдлийн хяналтын дүнг ашигладаг бөгөөд файлын өгөгдлийн хяналтын дүнг ашиглаж болно. Файлыг унших эсвэл бичихдээ систем нь хяналтын дүнг зөв эсэхийг шалгадаг. Ийнхүү эвдэрсэн өгөгдлийг бодит цаг хугацаанд нь илрүүлдэг.
ReFS нь Disk Space функцтэй нэгтгэгдсэн болно. Хэрэв та толин тусгал өгөгдлийн дэлгүүр тохируулсан бол Windows нь ReFS -ийг ашиглан өөр дискнээс өгөгдөл хуулж файлын системийн эвдрэлийг илрүүлж автоматаар засдаг. Энэ функцийг Windows 10 болон Windows 8.1 дээр ашиглах боломжтой.
Хэрэв файлын систем нь сэргээх өөр хувилбаргүй эвдэрсэн өгөгдлийг илрүүлсэн бол ReFS ийм өгөгдлийг дискнээс нэн даруй устгах болно. NTFS -тэй адил системийг дахин ачаалах эсвэл хадгалах төхөөрөмжийг салгах шаардлагагүй болно.
Алдаа гарсан үед файлын системийг автоматаар засдаг тул chkdsk хэрэгслийг ашиглах хэрэгцээ бүрэн арилдаг. Шинэ систем нь бусад төрлийн өгөгдлийн авлигад тэсвэртэй байдаг. NTFS нь файлын мета өгөгдлийг бичихдээ файлын мета өгөгдлийг шууд бичдэг. Хэрэв энэ хугацаанд цахилгаан тасарсан эсвэл компьютер осолдсон бол та өгөгдлийн эвдрэлийг хүлээж авах болно.
Мета өгөгдөл өөрчлөгдөхөд ReFS нь өгөгдлийн шинэ хуулбарыг үүсгэж, зөвхөн мета өгөгдлийг диск дээр бичсний дараа өгөгдлийг файлтай холбодог. Энэ нь өгөгдлийн авлигад өртөх магадлалыг арилгадаг. Энэ функцийг хуулбарлах гэж нэрлэдэг бөгөөд энэ нь бусад алдартай Linux үйлдлийн системүүд дээр байдаг: ZFS, BtrFS, Apple-ийн APFS файлын систем.
ReFS нь илүү орчин үеийн бөгөөд NTFS -ээс хамаагүй том хэмжээтэй, урт файлын нэрийг дэмждэг. Урт хугацаанд эдгээр нь чухал сайжруулалтууд юм. NTFS -д файлын нэр 255 тэмдэгтээр хязгаарлагддаг бол ReFS -д файлын нэр 32768 тэмдэгт хүртэл байж болно. Windows 10 нь NTFS файлын системийн тэмдэгтийн хязгаарыг идэвхгүй болгох боломжийг олгодог боловч ReFS эзлэхүүн дээр үргэлж идэвхгүй болдог.
ReFS нь DOS 8.3 форматтай богино файлын нэрийг дэмжихээ больсон. NTFS эзлэхүүн дээр та хандах боломжтой C: \ Програмын файлууд \ v C: \ ХӨТӨЛБӨР ~ 1 \хуучин програм хангамжтай нийцтэй байдлыг хангах.
NTFS нь онолын хамгийн дээд хэмжээ нь 16 экзабайт, ReFS нь онолын хамгийн дээд хэмжээ нь 262,144 экзабайт юм. Хэдийгээр энэ нь одоо хамаагүй боловч компьютерууд байнга хөгжиж байдаг.
ReFS нь файлын системийн гүйцэтгэлийг NTFS дээр сайжруулах зорилгоор хийгдээгүй болно. Майкрософт ReFS -ийг маш тодорхой тохиолдолд илүү үр дүнтэй болгосон.
Жишээлбэл, дискний зайг ашиглах үед ReFS нь "бодит цагийн оновчлол" -ыг дэмждэг. Та хоёр дисктэй хадгалах сантай гэж үзье, нэг нь хамгийн их гүйцэтгэлтэй, нөгөө нь багтаамжтай. ReFS нь хамгийн өндөр гүйцэтгэлтэй байхын тулд өгөгдлийг илүү хурдан диск рүү бичих болно. Цаана нь файлын систем нь урт хугацааны хадгалалтанд зориулан их хэмжээний өгөгдлийг автоматаар удаан диск рүү зөөх болно.
Windows Server 2016 дээр Microsoft нь ReFS -ийг сайжруулж виртуал машины үйл ажиллагааг илүү сайн гүйцэтгэдэг. Microsoft Hyper-V виртуал машин нь эдгээр давуу талыг ашигладаг (онолын хувьд аливаа виртуал машин ReFS-ийн давуу талыг ашиглах боломжтой).
Жишээлбэл, ReFS нь блок клончлолыг дэмждэг бөгөөд энэ нь виртуал машиныг клончлох, шалгах цэгийг нэгтгэх үйл явцыг хурдасгадаг. Виртуал машины хуулбарыг үүсгэхийн тулд ReFS нь зөвхөн шинэ мета өгөгдлийг диск рүү бичиж, одоо байгаа өгөгдлийн холбоосыг өгөх шаардлагатай. Учир нь ReFS дээр олон файлууд диск дээрх ижил өгөгдлийг зааж өгч болно.
Виртуал машин шинэ өгөгдлийг диск рүү бичих үед энэ нь өөр байршилд бичигдэх бөгөөд виртуал машины анхны өгөгдөл диск дээр үлддэг. Энэ нь хуулбарлах үйл явцыг ихээхэн хурдасгаж, дискний зурвасын өргөнийг бага шаарддаг.
ReFS нь бас шинэ функцийг санал болгодог "Ховор VDL"Энэ нь ReFS -ийг тэг файлуудыг том файлд хурдан бичих боломжийг олгодог. Энэ нь шинэ, хоосон, тогтмол хэмжээтэй виртуал хатуу диск (VHD) файл үүсгэхийг ихээхэн хурдасгадаг. NTFS дээр энэ үйлдэл 10 минут, ReFS дээр хэдэн секунд болно.
Хэд хэдэн давуу талтай хэдий ч ReFS нь NTFS -ийг орлож чадахгүй байна. Windows ReFS хуваалтаас ачаалах боломжгүй бөгөөд NTFS шаарддаг. ReFS нь өгөгдөл шахах, файлын системийн шифрлэлт, хатуу холбоосууд, өргөтгөсөн атрибутууд, өгөгдлийн хуулбарлах, дискний квот зэрэг NTFS функцийг дэмждэггүй. Гэхдээ NTFS -ээс ялгаатай нь ReFS нь BitLocker ашиглан системийн хөтчийн бүтцийг багтаасан драйверыг бүрэн шифрлэх боломжийг олгодог.
Windows 10 нь ReFS ашиглан хуваалтыг форматлахыг зөвшөөрдөггүй, энэ файлын системийг зөвхөн дискний зайд ашиглах боломжтой. ReFS нь олон хатуу дискний санд ашиглагддаг өгөгдлийг эвдрэлээс хамгаалдаг. Windows Server 2016 дээр та эзлэхүүнийг NTFS -ийн оронд ReFS ашиглан форматлаж болно. Ийм эзлэхүүнийг виртуал машин хадгалахад ашиглаж болох боловч үйлдлийн системийг зөвхөн NTFS -ээс ачаалах боломжтой хэвээр байна.
Hetman Partition Recovery нь гарын үсгийн анализын алгоритмыг ашиглан ReFS файлын системийн удирддаг дискний зайг шинжлэх боломжийг олгодог. Төхөөрөмжийн салбарыг салбараар нь шинжилснээр програм нь тодорхой байтын дарааллыг олж, хэрэглэгчдэд харуулдаг. ReFS дискний зайнаас өгөгдлийг сэргээх нь NTFS файлын системтэй ажиллахаас ялгаатай биш юм.
Шинэ файлын системийн ирээдүй бүрхэг байна. Майкрософт Windows -ийн бүх хувилбаруудад хоцрогдсон NTFS -ийг орлуулахын тулд ReFS -ийг эцэслэн боловсруулж магадгүй юм. Одоогийн байдлаар ReFS -ийг бүх нийтээр ашиглах боломжгүй бөгөөд зөвхөн тодорхой ажлуудад зориулагдсан болно.
Хэрэв та Microsoft: Windows Server 2012, Windows 8 -ээс шинэ OS суулгаж, ажиллаж байсан бол ReFS файлын системд шинэ эзлэхүүнийг форматлах боломжтой болохыг та анзаарсан байх. Файлын систем гэж юу вэ ReFS? ReFS гэдэг нь товчлол юм Уян хатан файлын систем, өөрөөр хэлбэл Орос хэл дээр "Алдаанд тэсвэртэй файлын систем".
Майкрософт нь ReFS файлын системийг өнөөгийн хамгийн алдартай файлын систем болох NTFS -ийн залгамжлагч гэж үздэг бөгөөд технологийн чадавхи нь аль хэдийн хязгаартаа хүрсэн байна. Ялангуяа том өгөгдөл дамжуулагчтай ажиллахад тэдний ажилд бэрхшээл гардаг: алдаа шалгах ажиллагаа, сэтгүүлийн удаан ажиллагаа, NTFS файл дээрх файлын дээд хэмжээг хязгаарлахад хэтэрхий урт хугацаа шаардагддаг. систем.
ReFS -ийн ихэнх шинэлэг зүйлүүд нь файл, хавтасны бүтцийг бий болгох, удирдахад оршдог. Эдгээр функцууд нь алдааг автоматаар залруулах, өргөтгөх чадвар сайтай, Үргэлж Онлайнаар ажиллахад зориулагдсан болно. ReFS файлын системийн фолдерууд нь бүртгэлтэй файл бүхий хүснэгт хэлбэрээр бүтээгдсэн бөгөөд эдгээр нь өгөгдлийн сангаас мэддэг B + модны шаталсан бүтцийг хэрэгжүүлж, дэд хүснэгт болгон зохион байгуулж, өөрийн гэсэн шинж чанартай байж болно. Чөлөөт дискний зайг хүснэгтэд байрлуулсан болно.
ReFS -ийг хөгжүүлэхдээ дараахь зорилтуудыг хэрэгжүүлсэн.
ReFS -ийн гол шинж чанарууд
ReFS файлын системийн хязгаарлалт
ReFS нь өмнөх NTFS -ийн олон онцлог шинж чанар, семантикийг өвлөн авсан бөгөөд үүнд:
ReFS файлын системийн бүх өгөгдөлд одоогоор NTFS хуваалтуудад нэвтрэхэд ашигладаг ижил API -үүдээр дамжуулан хандах боломжтой болно.
ReFS нь дараах NTFS функцуудыг хүчингүй болгосон.
ReFS дэмжлэгийг Windows 8 болон Windows Server 2012 дээр зөвхөн өгөгдлийн эзлэхүүн дээр нэвтрүүлсэн. Өөрөөр хэлбэл, ReFS хуваалтуудыг үйлдлийн системийг суулгах, ачаалахад ашиглах боломжгүй юм. Цаг хугацаа өнгөрөх тусам ReFS нь илүү олон функцээр тоноглогдсон бөгөөд хуучирсан NTFS системийг бүрэн орлох боломжтой болно. Бүх шинэ боломжууд Windows 8 -ийн анхны үйлчилгээний багцад гарч ирэх магадлалтай.
Нэмж дурдахад ReFS -ийг зөөврийн болон зөөврийн хадгалах төхөөрөмжид хараахан ашиглах боломжгүй байна (ReFS -ийг одоогоор зөвхөн дотоод мэдээллийн хэрэгсэлд ашигладаг).
Сэтгэл дундуур байгаа зүйл бол одоо байгаа NTFS -ийн хэмжээг ReFS болгон хөрвүүлэх боломжгүй юм. Өгөгдлийг ердийн хуулбараар дамжуулах шаардлагатай болно.
Дискийг удирдах консолоор дамжуулан эзлэхүүнийг ReFS файлын системд форматлаж болно. Гэхдээ тууштай байдлыг шалгах зэрэг нэмэлт сонголтуудыг зөвхөн командын мөрөөс идэвхжүүлэх боломжтой.
Жишээлбэл, та ReFS -ийн нийцтэй байдлыг дараах тушаалаар идэвхжүүлж болно.
Формат / fs: refs / q / i: идэвхжүүлэх
Тогтвортой байдлын шалгалтыг идэвхгүй болгох.
