Для ўключэння ядро Linux 6.2 прапанаваны паляпшэнні Btrfs, датычныя выпраўлення праблемы "write hole" у рэалізацыі RAID 5/6. Сутнасць праблемы зводзіцца да таго, што калі крах здарыўся падчас запісу, першапачаткова немагчыма зразумець які блок на якой з прылад RAID запісаўся карэктна, а ў якім запіс не была завершана. У выпадку спробы аднаўлення RAID у падобнай сітуацыі можа адбыцца разбурэнне блокаў, якія адпавядаюць недазапісаным блокам, паколькі стан блокаў RAID рассінхранізаваны. Гэтая праблема ўзнікае ў любых масівах RAID1/5/6, дзе не прынята спецыяльных мер для барацьбы з падобным эфектам.
У рэалізацыі RAID, накшталт RAID1 у btrfs, гэтая праблема вырашаецца выкарыстаннем кантрольных сум у абедзвюх копіях, пры несупадзенні дадзеныя проста аднаўляюцца з другой копіі. Гэты падыход таксама спрацоўвае калі нейкая прылада пачынае аддаваць некарэктныя дадзеныя замест поўнай адмовы.
Аднак у выпадку RAID5/6 файлавая сістэма не захоўвае кантрольныя сумы для блокаў цотнасці: у звычайнай сітуацыі карэктнасць блокаў правяраецца тым фактам, што яны ўсё забяспечаны кантрольнай сумай, а блок цотнасці можна ўзнавіць з дадзеных. Аднак у выпадку частковага запісу гэты падыход у пэўных сітуацыях можа не спрацаваць. У гэтым выпадку, пры аднаўленні масіва не выключана, што блокі, якія трапілі пад незавершаны запіс, будуць адноўлены некарэктна.
У выпадку btrfs гэтая праблема найболей актуальная, калі вырабляны запіс па памеры менш страйпа. Пры гэтым файлавая сістэма павінна выканаць аперацыю чытання-мадыфікацыі-запісы (read-modify-write, RMW). Калі пры гэтым трапяцца блокі з незавершаным запісам, у такім выпадку аперацыя RMW можа выклікаць разбурэнні, якія не будуць выяўлены, нягледзячы на кантрольныя сумы. Распрацоўнікі занеслі змены, пры якіх аперацыя RMW правярае кантрольную суму блокаў да таго як вырабляць дадзеную аперацыю, а пры неабходнасці ўзнаўлення дадзеных выконвае і праверку кантрольных сум пасля запісу. Нажаль, у сітуацыі з запісам няпоўнага страйпа (RMW) гэта вядзе да дадатковых накладных выдаткаў на вылічэнне кантрольных сум, аднак значна падвышае надзейнасць. Для RAID6 такая логіка пакуль не гатовая, аднак для такой адмовы ў RAID6 неабходна каб запіс не атрымалася на адразу 2 прыладах, што меней верагодна.
Дадаткова можна адзначыць рэкамендацыі па выкарыстанні RAID5/6 ад распрацоўнікаў, іста якіх зводзіцца да таго, што ў Btrfs профіль захоўвання метададзеных і дадзеных можа адрознівацца. Пры гэтым можна выкарыстоўваць профіль RAID1 (люстэрка) ці нават RAID1C3 (3 копіі) для метададзеных, а для дадзеных RAID5 ці RAID6. Пры гэтым забяспечваецца надзейная абарона метададзеных і адсутнасць "write hole" з аднаго боку і больш эфектыўнае выкарыстанне месца, характэрнае для RAID5/6, з іншай. Гэта дазваляе пазбягаць разбурэнняў у метададзеных, а пашкоджанні дадзеных могуць быць выпраўлены.
Таксама можна адзначыць, што для SSD у Btrfs у ядры 6.2 будзе актываванае па змаўчанні асінхроннае выкананне аперацыі "discard" (пазнака вызваленых блокаў, якія ўжо можна не захоўваць фізічна). Вартасцю гэтага рэжыму з'яўляецца высокая прадукцыйнасць з-за эфектыўнай групоўкі аперацый "discard" у чарзе і далей апрацоўкі чаргі фонавым апрацоўшчыкам, з-за чаго нармальныя аперацыі ФС не запавольваюцца, як у выпадку з сінхронным "discard" па меры вызвалення блокаў, а SSD можа прымаць больш удалыя рашэнні. З іншага боку, больш не запатрабуецца выкарыстаць утыліты тыпу fstrim, паколькі ўсе даступныя блокі будуць чысціцца ў ФС без неабходнасці дадатковага сканавання і без запаволення аперацый.
Крыніца: opennet.ru