Ang isa pang feature na naka-iskedyul na ipadala para sa paparating na Linux 6.5 kernel merge window ay ang pagpapakilala ng suporta para sa provisioning primitives para sa thinly provisioned storage gamit ang Device Mapper (DM) code.
Ang isang sangay na ginawa noong katapusan ng linggo ay linux-dm.git’s dm-6.5-provision-support. Sa ngayon ay nasa isang sangay na minarkahan para sa”6.5″, lumilitaw na nakaposisyon na ipapadala para sa paparating na Linux 6.5 merge window na humahadlang sa anumang mga isyu na ilabas ni Linus Torvalds o iba pang mga kernel developer.
Ang mga provisioning primitive na ito ay ginawa ng Chrome OS team ng Google. Si Sarthak Kukreti ng Google ay dati nang ipinaliwanag ang inisyatiba na ito sa mga naunang RFC patch sa pagpapadala ng koreo list:
“Ang serye ng patch na ito ay isang RFC ng isang mekanismo upang ipasa ang mga kahilingan sa probisyon sa mga nakasalansan na manipis na provisioned na mga storage device/filesystem.
Ang linux kernel ay nagbibigay ng ilang mga mekanismo upang mag-set up ng manipis na provisioned block storage abstraction ( hal. dm-thin, loop na mga device sa mga kalat-kalat na file), direkta man bilang block device o backing storage para sa mga filesystem. Sa kasalukuyan, kulang sa pagsulat ng data sa alinman sa device o filesystem, walang paraan para sa mga user na maglaan ng espasyo para magamit sa naturang mga setup ng storage. Isaalang-alang ang mga sumusunod na use-case:
1) Suspindihin-sa-disk at ipagpatuloy mula sa isang dm-thin na device: Upang matiyak na ang pinagbabatayan na thinpool metadata ay hindi nabago sa panahon ng mekanismo ng pagsususpinde, ang dm-thin na device ay kailangang ganap na mai-provision.
2) Kung ang isang filesystem ay gumagamit ng loop device sa ibabaw ng kalat-kalat na file, ang fallocate() sa filesystem ay maglalaan ng mga bloke para sa mga file ngunit ang pinagbabatayan na kalat-kalat na file ay mananatiling buo.
3) Ang isa pang halimbawa ay ang virtual machine na gumagamit ng kalat-kalat na file/dm-thin bilang storage device; bilang default, ang mga alokasyon sa loob ng mga hangganan ng VM ay hindi makakaapekto sa host.
4) Sinusuportahan ng ilang pamantayan ng storage ang mga mekanismo para sa manipis na provisioning sa mga tunay na hardware device. Halimbawa:
a. Ang NVMe spec 1.0b section 2.1.1 ay maluwag na nagsasalita tungkol sa manipis na provisioning:”Kapag ang THINP bit sa NSFEAT field ng Identify Namespace data structure ay nakatakda sa’1′, ang controller… ang patlang na Paggamit ng Namespace”
b. Ang sanggunian ng SCSi Block Commands-4 na seksyong mga sanggunian na”Thin provisioned logical units”,
c. UFS 3.0 spec section 13.3.3 references”Thin provisioning”.Sa lahat ng sitwasyon sa itaas, sa kasalukuyan ang tanging paraan para sa paunang paglalaan ng puwang ay ang mag-isyu ng mga pagsusulat (o gumamit ng WRITE_ZEROES/WRITE_SAME). Gayunpaman, hindi iyon nasusukat nang maayos sa mas malalaking sukat ng pre-allocation.
Ang patchset na ito ay nagpapakilala ng mga primitive upang suportahan ang block-level na provisioning (tandaan: ang terminong’provisioning’ay ginagamit upang maiwasan ang labis na karga ng terminong’allocations/pre-allocations’) na mga kahilingan sa mga filesystem at block device. Nagbibigay-daan ito sa fallocate() at mga kahilingan sa paggawa ng file na magreserba ng espasyo sa mga nakasalansan na layer ng mga block device at filesystem. Sa kasalukuyan, sinasaklaw ng patchset ang isang prototype sa mga target ng device-mapper, loop device at ext4, ngunit ang parehong mekanismo ay maaaring i-extend sa iba pang mga filesystem/block device pati na rin palawigin para magamit sa mga device sa 4 a-c.”
Ang patch na nagpapakilala sa REQ_OP_PROVISION na kahilingan ay nagbubuod lang ng provisioning na ito bilang:
“Introduce block request REQ_OP_PROVISION. Ang layunin ng kahilingang ito ay humiling ng pinagbabatayan na imbakan upang paunang maglaan ng espasyo sa disk para sa ibinigay na hanay ng block. I-block ang mga device na sumusuporta sa kakayahang ito ay mag-e-export ng limitasyon sa probisyon sa loob ng kanilang mga queue ng kahilingan.
Idinaragdag din ng patch na ito ang kakayahang tumawag ng fallocate() sa mode 0 sa mga block device, na magpapadala ng REQ_OP_PROVISION sa block device para sa tinukoy na hanay,”
Ang block provisioning primitives na ito ang trabaho ay nasa trabaho sa loob ng ilang buwan at matagumpay na nasubok sa Chrome OS at laban sa upstream na Linux kernel. Ang block at DM ay nagbabago sa paligid ng REQ_OP_PROVISION pati na rin ang loopback na suporta ng device para dito ay handa na ngayong lumabas sa Linux 6.5.
Ang Linux 6.5 merge window ay inaasahang magsisimula sa susunod na linggo kung ang Linux 6.4 stable na release ay hindi maibabalik ng dagdag na linggo. Ang Linux 6.5 stable naman ay dapat mag-debut sa pagtatapos ng Agosto.
