Трајно складиштење података и АПИ-ји за Линук датотеке

Истражујући одрживост складиштења података у клауд системима, одлучио сам да се тестирам како бих се уверио да разумем основне ствари. И започето читањем НВМе спецификације да бисмо разумели које гаранције у вези са одрживим складиштењем података (тј. гаранције да ће подаци бити доступни након квара система) нам дају НМВе дискове. Донео сам следеће главне закључке: подаци се морају сматрати оштећеним од тренутка када је дата команда за упис података до тренутка када су уписани на медиј за складиштење. Међутим, већина програма прилично срећно користи системске позиве за снимање података.

У овом посту истражујем трајне механизме складиштења које пружају АПИ-ји за Линук датотеке. Чини се да би овде све требало да буде једноставно: програм позива команду write(), а након што се ова команда заврши, подаци ће бити безбедно сачувани на диску. Али write() копира само податке апликације у кеш кернел који се налази у РАМ-у. Да бисте натерали систем да запише податке на диск, потребно је да користите неке додатне механизме.

Све у свему, овај материјал је збирка белешки које се односе на оно што сам научио о теми која ме занима. Ако врло кратко говоримо о најважнијем, испада да је за организовање одрживог складиштења података потребно користити команду fdatasync() или отворите датотеке са заставицом O_DSYNC. Ако сте заинтересовани да сазнате више о томе шта се дешава са подацима на њиховом путу од кода до диска, погледајте ово чланак.

Карактеристике коришћења функције врите().

Системски позив write() дефинисано у стандарду ИЕЕЕ ПОСИКС као покушај уписивања података у дескриптор датотеке. Након успешног завршетка write() Операције читања података морају да врате тачно бајтове који су претходно написани, чинећи то чак и ако се подацима приступа из других процеса или нити (овде релевантни део стандарда ПОСИКС). Овде, у одељку о томе како нити комуницирају са нормалним операцијама датотека, постоји напомена која каже да ако две нити позивају ове функције, онда сваки позив мора да види или све назначене последице другог позива, или ниједну. последице. Ово доводи до закључка да све И/О операције датотеке морају држати закључавање на ресурсу на којем раде.

Да ли то значи да је операција write() да ли је атомски? Са техничке тачке гледишта, да. Операције читања података морају вратити или све или ништа од онога што је написано write(). Али операција write(), према стандарду, не мора нужно да се заврши тако што ће записати све што је затражено. Дозвољено јој је да упише само део података. На пример, могли бисмо да имамо две нити од којих свака додаје 1024 бајта датотеци коју описује исти дескриптор датотеке. Са становишта стандарда, прихватљив резултат ће бити када свака операција писања може додати само један бајт датотеци. Ове операције ће остати атомске, али након што се заврше, подаци које су уписали у датотеку ће бити помешани. ovde је веома интересантна дискусија на ову тему на Стацк Оверфлов-у.

функције фсинц() и фдатасинц().

Најлакши начин за избацивање података на диск је да позовете функцију фсинц(). Ова функција тражи од оперативног система да пренесе све модификоване блокове из кеша на диск. Ово укључује све метаподатке датотеке (време приступа, време модификације датотеке итд.). Верујем да су ови метаподаци ретко потребни, па ако знате да вам нису важни, можете користити функцију fdatasync(). У помоћ на fdatasync() каже се да се током рада ове функције на диск чува толика количина метаподатака која је „неопходна за исправно извршење следећих операција читања података“. А то је управо оно о чему већина апликација брине.

Један проблем који се овде може појавити је тај што ови механизми не гарантују да ће датотека бити откривена након могућег квара. Конкретно, када креирате нову датотеку, морате позвати fsync() за директоријум који га садржи. У супротном, након грешке, може се испоставити да ова датотека не постоји. Разлог за то је што у УНИКС-у, због употребе чврстих веза, датотека може постојати у више директоријума. Стога, приликом позивања fsync() не постоји начин да датотека зна које податке директоријума такође треба избацити на диск (овде Можете прочитати више о овоме). Изгледа да је ект4 систем датотека способан аутоматски да се пријаве fsync() у директоријуме који садрже одговарајуће датотеке, али то можда није случај са другим системима датотека.

Овај механизам може бити различито имплементиран на различитим системима датотека. користио сам блктраце да сазнате које се операције диска користе у ект4 и КСФС системима датотека. И један и други издају редовне команде за писање на диск и за садржај датотеке и за дневник система датотека, испразне кеш и изађу извођењем ФУА (присилног приступа јединици, уписивање података директно на диск, заобилазећи кеш) уписивање у дневник. Они то вероватно раде како би потврдили да је трансакција извршена. На диск јединицама које не подржавају ФУА, ово узрокује два испирања кеша. Моји експерименти су то показали fdatasync() мало брже fsync(). Корисност blktrace указује на то fdatasync() обично записује мање података на диск (у ект4 fsync() пише 20 КиБ, и fdatasync() - 16 КиБ). Такође, сазнао сам да је КСФС нешто бржи од ект4. И овде уз помоћ blktrace успео да то сазна fdatasync() испушта мање података на диск (4 КиБ у КСФС).

Двосмислене ситуације које настају када се користи фсинц()

Могу да се сетим три двосмислене ситуације у вези fsync()са којима сам се сусрео у пракси.

Први такав случај догодио се 2008. Тада се интерфејс Фирефок 3 замрзнуо ако је велики број датотека уписан на диск. Проблем је био у томе што је имплементација интерфејса користила СКЛите базу података за чување информација о свом стању. Након сваке промене која се догодила у интерфејсу, функција је била позвана fsync(), што је дало добре гаранције за стабилно складиштење података. У ект3 систему датотека који се тада користи, функција fsync() избацио све „прљаве“ странице у систему на диск, а не само оне које су биле повезане са одговарајућом датотеком. То је значило да би клик на дугме у Фирефок-у могао да покрене запис мегабајта података на магнетни диск, што би могло да потраје много секунди. Решење проблема, колико сам разумео из то материјал је био да се рад са базом података пренесе на асинхроне позадинске задатке. То значи да је Фирефок раније имплементирао строже захтеве за складиштење него што је заиста било потребно, а карактеристике ект3 система датотека само су погоршале овај проблем.

Други проблем се догодио 2009. Затим, након пада система, корисници новог ект4 система датотека су се суочили са чињеницом да многе новонастале датотеке имају нулту дужину, али се то није десило са старијим ект3 системом датотека. У претходном пасусу сам говорио о томе како је ект3 избацио превише података на диск, што је доста успорило ствари. fsync(). Да би се ситуација побољшала, у ект4 само оне прљаве странице које су релевантне за одређену датотеку се испуштају на диск. А подаци из других датотека остају у меморији много дуже него код ект3. Ово је урађено да би се побољшале перформансе (подразумевано, подаци остају у овом стању 30 секунди, ово можете да конфигуришете помоћу дирти_екпире_центисецс; овде Можете пронаћи додатне материјале о томе). То значи да велика количина података може бити неповратно изгубљена након квара. Решење овог проблема је употреба fsync() у апликацијама које треба да обезбеде стабилно складиштење података и заштите их што је више могуће од последица кварова. Функција fsync() ради много ефикасније када користите ект4 него када користите ект3. Недостатак овог приступа је што његова употреба, као и до сада, успорава извршавање неких операција, као што је инсталирање програма. Погледајте детаље о овоме овде и овде.

Трећи проблем у вези fsync(), настао 2018. године. Затим је у оквиру ПостгреСКЛ пројекта утврђено да ако функција fsync() наиђе на грешку, "прљаве" странице означава као "чисте". Као резултат, следећи позиви fsync() Они не раде ништа са таквим страницама. Због тога се измењене странице чувају у меморији и никада се не уписују на диск. Ово је права катастрофа, пошто ће апликација мислити да су неки подаци уписани на диск, али у ствари то неће бити. Такви неуспеси fsync() су ретке, примена у таквим ситуацијама не може учинити скоро ништа у борби против проблема. Ових дана, када се то догоди, ПостгреСКЛ и друге апликације падају. Овде, у материјалу „Могу ли се апликације опоравити од фсинц грешака?“, овај проблем је детаљно истражен. Тренутно најбоље решење за овај проблем је коришћење Дирецт И/О са заставицом O_SYNC или са заставом O_DSYNC. Са овим приступом, систем ће пријавити грешке које се могу појавити током одређених операција писања, али овај приступ захтева да апликација сама управља баферима. Прочитајте више о овоме овде и овде.

Отварање датотека помоћу ознака О_СИНЦ и О_ДСИНЦ

Вратимо се дискусији о Линук механизмима који обезбеђују стабилно складиштење података. Наиме, говоримо о коришћењу заставе O_SYNC или застава O_DSYNC приликом отварања датотека помоћу системског позива отворен (). Са овим приступом, свака операција писања података се изводи као после сваке команде write() систему се дају команде у складу са тим fsync() и fdatasync(). У ПОСИКС спецификације ово се зове „Довршење интегритета синхронизоване И/О датотеке“ и „Довршење интегритета података“. Главна предност овог приступа је да да бисте осигурали интегритет података, потребно је само један системски позив, а не два (нпр. write() и fdatasync()). Главни недостатак овог приступа је што ће сви записи који користе одговарајући дескриптор датотеке бити синхронизовани, што може ограничити могућност структурирања кода апликације.

Коришћење Дирецт И/О са О_ДИРЕЦТ заставицом

Системски позив open() подржава заставу O_DIRECT, који је дизајниран да заобиђе кеш оперативног система за обављање И/О операција директном интеракцијом са диском. То у многим случајевима значи да ће наредбе за писање које издаје програм бити директно преведене у команде које имају за циљ рад ​​са диском. Али, генерално, овај механизам није замена за функције fsync() или fdatasync(). Чињеница је да сам диск може одложити или кеширати одговарајуће команде за писање података. И, да ствар буде још гора, у неким посебним случајевима И/О операције се обављају када се користи заставица O_DIRECT, емитовање у традиционалне бафероване операције. Најлакши начин да решите овај проблем је да користите заставицу за отварање датотека O_DSYNC, што ће значити да ће свака операција писања бити праћена позивом fdatasync().

Испоставило се да је КСФС систем датотека недавно додао "брзу путању" за O_DIRECT|O_DSYNC- снимање података. Ако се блок поново пише помоћу O_DIRECT|O_DSYNC, онда ће КСФС, уместо испирања кеша, извршити ФУА команду за писање ако је уређај подржава. Ово сам проверио користећи услужни програм blktrace на систему Линук 5.4/Убунту 20.04. Овај приступ би требало да буде ефикаснији, јер када се користи, минимална количина података се уписује на диск и користи се једна операција, а не две (писање и испирање кеша). Нашао сам везу до закрпа 2018 кернел, који имплементира овај механизам. Постоји нека дискусија о примени ове оптимизације на друге системе датотека, али колико ја знам, КСФС је једини систем датотека који ово подржава.

синц_филе_ранге() функција

Линук има системски позив синц_филе_ранге(), што вам омогућава да испразните само део датотеке на диск, а не целу датотеку. Овај позив покреће асинхроно испирање података и не чека да се заврши. Али у сертификату sync_file_range() за тим се каже да је „веома опасан“. Није препоручљиво користити га. Карактеристике и опасности sync_file_range() веома добро описано у ово материјал. Конкретно, чини се да овај позив користи РоцксДБ за контролу када кернел избаци прљаве податке на диск. Али у исто време, да би се обезбедило стабилно складиштење података, такође се користи fdatasync(). У код РоцксДБ има неколико занимљивих коментара на ову тему. На пример, чини се да позив sync_file_range() Када користите ЗФС, он не испушта податке на диск. Искуство ми говори да код који се ретко користи вероватно садржи грешке. Због тога бих саветовао да не користите овај системски позив осим ако није апсолутно неопходно.

Системски позиви који помажу да се обезбеди постојаност података

Дошао сам до закључка да постоје три приступа која се могу користити за извођење И/О операција које осигуравају постојаност података. Сви они захтевају позив функције fsync() за директоријум у коме је датотека креирана. Ово су приступи:

1. Позив функције fdatasync() или fsync() после функције write() (боље је користити fdatasync()).
2. Рад са дескриптором датотеке отвореним са заставицом O_DSYNC или O_SYNC (боље - са заставом O_DSYNC).
3. Користећи команду pwritev2() са заставом RWF_DSYNC или RWF_SYNC (по могућности са заставом RWF_DSYNC).

Напомене о перформансама

Нисам пажљиво мерио перформансе различитих механизама које сам испитивао. Разлике које сам приметио у брзини њиховог рада су веома мале. То значи да можда грешим и да под различитим условима иста ствар може дати различите резултате. Прво ћу говорити о томе шта више утиче на перформансе, а затим шта мање утиче на перформансе.

1. Замена података датотеке је бржа од додавања података у датотеку (корист од перформанси може бити 2-100%). Додавање података у датотеку захтева додатне промене у метаподацима датотеке, чак и након системског позива fallocate(), али величина овог ефекта може варирати. За најбоље перформансе препоручујем да позовете fallocate() да унапред додели потребан простор. Затим се овај простор мора експлицитно попунити нулама и позвати fsync(). Ово ће обезбедити да одговарајући блокови у систему датотека буду означени као „додељени“ уместо „недодељени“. Ово даје мало (око 2%) побољшање перформанси. Поред тога, неки дискови могу имати спорији први приступ блоку од других. То значи да попуњавање простора нулама може довести до значајног (око 100%) побољшања перформанси. Конкретно, то се може догодити са дисковима АВС ЕБС (ово су незванични подаци, нисам могао да потврдим). Исто важи и за складиштење ГЦП трајни диск (а ово је већ званична информација, потврђена тестовима). И други стручњаци су урадили исто posmatranje, везано за различите дискове.
2. Што је мање системских позива, то су перформансе веће (добитак може бити око 5%). Изгледа као изазов open() са заставом O_DSYNC или позовите pwritev2() са заставом RWF_SYNC брже од позива fdatasync(). Претпостављам да је поента овде у томе што овај приступ игра улогу у чињеници да се мора извршити мање системских позива да би се решио исти проблем (један позив уместо два). Али разлика у перформансама је веома мала, тако да је можете потпуно игнорисати и користити нешто у апликацији што неће компликовати њену логику.

Ако сте заинтересовани за тему одрживог складиштења података, ево неколико корисних материјала:

• И/О методе приступа — преглед основа улазно/излазних механизама.
• Обезбеђивање да подаци стигну до диска — прича о томе шта се дешава са подацима на путу од апликације до диска.
• Када треба фсинц директоријум који садржи - одговор на питање кога користити fsync() за именике. Укратко, испоставило се да то треба да урадите када креирате нову датотеку, а разлог за ову препоруку је тај што у Линуку може бити много референци на исту датотеку.
• СКЛ Сервер на Линук-у: ФУА Интерналс — ево описа како је трајно складиштење података имплементирано у СКЛ Сервер на Линук платформи. Овде постоје нека занимљива поређења између Виндовс и Линук системских позива. Готово сам сигуран да сам захваљујући овом материјалу научио о ФУА оптимизацији КСФС-а.

Да ли сте изгубили податке за које сте мислили да су безбедно ускладиштени на диску?

Извор: ввв.хабр.цом