Kasama sa Linux 6.2 ang mga pagpapahusay sa RAID5 at RAID6 sa Btrfs

Linux Kernel

Linux Kernel

Kamakailan lang ay ipinahayag iyon Ang mga pagpapabuti sa Btrfs ay iminungkahi para sa pagsasama sa Linux 6.2 kernel upang ayusin ang isyu ng write hole sa pagpapatupad ng RAID 5/6.

Ang kakanyahan ng problema ay bumababa sa katotohanan na kung ang isang pag-crash ay nangyari sa panahon ng pag-record, sa una ay imposibleng maunawaan kung aling bloke kung alin sa mga RAID device ang isinulat nang tama, at kung saan ang pag-record ay hindi nakumpleto.

Kung susubukan mong muling buuin ang isang RAID sa sitwasyong ito, ang mga bloke na nauugnay sa mga naka-subscribe na bloke ay maaaring masira dahil ang estado ng mga bloke ng RAID ay hindi naka-sync. Ang problemang ito ay nangyayari sa anumang RAID1/5/6 array kung saan walang mga espesyal na hakbang ang ginawa upang labanan ang epektong ito.

Sa isang pagpapatupad ng RAID tulad ng RAID1 sa btrfs, nalutas ang problemang ito sa pamamagitan ng paggamit ng mga checksum sa parehong mga kopya, kung mayroong hindi tugma, ang data ay naibalik lamang mula sa pangalawang kopya. Gumagana rin ang diskarteng ito kung ang anumang device ay nagsimulang magbigay ng masamang data sa halip na ganap na mabigo.

Gayunpaman, sa kaso ng RAID5/6, ang file system ay hindi nag-iimbak ng mga checksum para sa mga bloke ng parity - sa isang normal na sitwasyon, ang kawastuhan ng mga bloke ay nasuri sa pamamagitan ng katotohanan na lahat sila ay nilagyan ng checksum, at ang parity block ay maaaring muling likhain mula sa data. Gayunpaman, sa kaso ng bahagyang pag-record, maaaring hindi gumana ang diskarteng ito sa ilang partikular na sitwasyon. Sa kasong ito, kapag nire-restore ang array, posible iyon ang mga bloke na natitira sa hindi kumpletong tala ay naibalik nang hindi tama.

Sa kaso ng btrfs, ang problemang ito ay mas may kaugnayan kung ang pagsusulat na nangyayari ay mas maliit kaysa sa guhit. Sa kasong ito, ang file system ay dapat magsagawa ng read-modify-write (RMW) na operasyon.

Kung makakatagpo ito ng mga write-in-progress na block, ang operasyon ng RMW ay maaaring magdulot ng katiwalian na hindi matukoy, anuman ang mga checksum. Ang mga developer ay gumawa ng mga pagbabago kung saan ang operasyon ng RMW ay nagpapatunay sa checksum ng mga bloke bago isagawa ang operasyong ito, at kung kinakailangan, ang pagbawi ng data ay nagsasagawa rin ng checksum na pag-verify pagkatapos ng pagsulat.

Sa kasamaang palad, sa isang sitwasyon kung saan nakasulat ang isang hindi kumpletong fringe (RMW), lumilikha ito ng karagdagang overhead upang makalkula ang mga checksum, ngunit makabuluhang pinapataas ang pagiging maaasahan. Para sa RAID6, ang gayong lohika ay hindi pa handa,

Bilang karagdagan, maaari naming tandaan ang mga rekomendasyon sa paggamit ng RAID5/6 mula sa mga developer, ang kakanyahan nito ay sa Btrfs ang profile para sa pag-iimbak ng metadata at data ay maaaring magkakaiba. Sa kasong ito, maaari mong gamitin ang RAID1 (mirror) o kahit na RAID1C3 (3 kopya) na profile para sa metadata, at RAID5 o RAID6 para sa data.

Tinitiyak nito ang maaasahang proteksyon ng metadata at ang kawalan ng "write hole" sa isang banda, at mas mahusay na paggamit ng espasyo, tipikal ng RAID5/6, sa kabilang banda. Pinipigilan nito ang katiwalian ng metadata at maaaring itama ang katiwalian ng data.

Rin Mapapansin na para sa mga SSD sa Btrfs sa kernel 6.2, la asynchronous na pagpapatupad ng "discard" na operasyon (markahan ang mga napalaya na bloke na hindi na pisikal na maiimbak) ay naka-on bilang default.

Ang bentahe nito mode ay mataas na pagganap dahil sa mahusay na pagpapangkat ng mga operasyon sa pag-discard sa isang queue at post-processing ng queue ng isang background handler, kaya ang mga normal na operasyon ng FS ay hindi pinabagal tulad ng kaso sa kasabay na "i-discard" habang ang mga bloke ay napalaya, at ang SSD ay maaaring maging mas mahusay mga desisyon. Sa kabilang banda, hindi mo na kakailanganing gumamit ng mga utility tulad ng fstrim, dahil ang lahat ng magagamit na mga bloke ay mabubura sa FS nang hindi nangangailangan ng karagdagang pag-scan at nang hindi nagpapabagal sa mga operasyon.

Panghuli, kung interesado kang malaman ang tungkol dito, maaari kang kumunsulta sa mga detalye sa ang sumusunod na link.


Iwanan ang iyong puna

Ang iyong email address ay hindi nai-publish. Mga kinakailangang patlang ay minarkahan ng *

*

*

  1. Responsable para sa data: AB Internet Networks 2008 SL
  2. Layunin ng data: Kontrolin ang SPAM, pamamahala ng komento.
  3. Legitimation: Ang iyong pahintulot
  4. Komunikasyon ng data: Ang data ay hindi maiparating sa mga third party maliban sa ligal na obligasyon.
  5. Imbakan ng data: Ang database na naka-host ng Occentus Networks (EU)
  6. Mga Karapatan: Sa anumang oras maaari mong limitahan, mabawi at tanggalin ang iyong impormasyon.