Трајно складирање податоци и API-и за датотеки на Linux

Додека ја истражував одржливоста на складирањето податоци во облак системите, решив да се тестирам за да се уверам дека ги разбирам основните работи. Јас започна со читање на спецификацијата NVMe со цел да разбереме какви гаранции во врска со одржливото складирање податоци (т.е. гаранции дека податоците ќе бидат достапни по дефект на системот) ни даваат NMVe дискови. Ги направив следните главни заклучоци: податоците мора да се сметаат за оштетени од моментот кога е дадена наредбата за запишување податоци до моментот кога се запишуваат во медиумот за складирање. Сепак, повеќето програми сосема среќно користат системски повици за снимање податоци.

Во овој пост, ги истражувам механизмите за постојано складирање обезбедени од API-ите на датотеките на Linux. Се чини дека сè треба да биде едноставно тука: програмата ја повикува командата write(), и откако оваа команда ќе заврши, податоците ќе бидат безбедно зачувани на дискот. Но write() само ги копира податоците од апликацијата во кешот на јадрото лоциран во RAM меморијата. За да го принудите системот да запишува податоци на дискот, треба да користите некои дополнителни механизми.

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

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

Системски повик write() дефинирани во стандардот IEEE POSIX како обид за запишување податоци во дескриптор на датотека. По успешното завршување write() Операциите за читање податоци мора да ги вратат точно бајтите кои биле претходно напишани, правејќи го тоа дури и ако до податоците се пристапува од други процеси или нишки (тука релевантен дел од стандардот POSIX). Тука, во делот за тоа како нишките комуницираат со нормалните операции на датотеките, постои забелешка која вели дека ако секоја од две нишки ги повикува овие функции, тогаш секој повик мора да ги види или сите назначени последици од другиот повик, или воопшто нема. последиците. Ова води до заклучок дека сите операции за влез/излез на датотеки мора да држат заклучување на ресурсот на кој работат.

Дали ова значи дека операцијата write() дали е атомски? Од техничка гледна точка, да. Операциите за читање податоци мора да вратат или се или ништо од напишаното со write(). Но операцијата write(), според стандардот, не мора нужно да заврши со запишување на сè што е побарано да се запише. Дозволено ѝ е да напише само дел од податоците. На пример, може да имаме две нишки кои додаваат по 1024 бајти на датотека опишана од истиот дескриптор на датотеката. Од гледна точка на стандардот, прифатлив резултат ќе биде кога секоја операција за запишување може да додаде само еден бајт на датотеката. Овие операции ќе останат атомски, но откако ќе бидат завршени, податоците што ги напишале во датотеката ќе бидат измешани. тука е многу интересна дискусија на оваа тема на Stack Overflow.

Функциите fsync() и fdatasync().

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

Еден проблем што може да се појави овде е тоа што овие механизми не гарантираат дека датотеката ќе може да се открие по можен дефект. Особено, кога креирате нова датотека, треба да се јавите fsync() за директориумот што го содржи. Во спротивно, по неуспех, може да испадне дека оваа датотека не постои. Причината за ова е што во UNIX, поради употребата на тврди врски, датотека може да постои во повеќе директориуми. Затоа, кога се јавувате fsync() не постои начин датотеката да знае кои податоци од директориумот исто така треба да се исфрлат на дискот (тука Можете да прочитате повеќе за ова). Изгледа дека датотечниот систем ext4 е способен автоматски да се примени fsync() до директориумите што ги содржат соодветните датотеки, но тоа можеби не е случај со другите датотечни системи.

Овој механизам може да се имплементира различно на различни датотечни системи. користев blktrace да дознаете за тоа кои операции на дискот се користат во датотечните системи ext4 и XFS. И двете издаваат редовни команди за пишување на дискот и за содржината на датотеката и за дневникот на датотечниот систем, го измиваат кешот и излегуваат со извршување на FUA (Force Unit Access, пишување податоци директно на дискот, заобиколување на кешот) запишување во дневникот. Тие веројатно го прават тоа за да потврдат дека трансакцијата е извршена. На дисковите што не поддржуваат FUA, ова предизвикува две испирање на кешот. Моите експерименти го покажаа тоа fdatasync() малку побрзо fsync(). Алатка blktrace укажува на тоа fdatasync() обично пишува помалку податоци на дискот (во ext4 fsync() пишува 20 KiB, и fdatasync() - 16 KiB). Исто така, дознав дека XFS е малку побрз од ext4. И тука со помош blktrace успеа да го дознае тоа fdatasync() исфрла помалку податоци на дискот (4 KiB во XFS).

Двосмислени ситуации што се појавуваат при користење на fsync()

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

Првиот таков случај се случи во 2008 година. Потоа интерфејсот на Firefox 3 се замрзна ако голем број датотеки се напишани на дискот. Проблемот беше што имплементацијата на интерфејсот користеше база на податоци SQLite за складирање на информации за неговата состојба. По секоја промена што се случуваше во интерфејсот, функцијата беше повикана fsync(), што даде добри гаранции за стабилно складирање на податоци. Во датотечен систем ext3 што потоа се користи, функцијата fsync() ги фрли сите „валкани“ страници во системот на дискот, а не само оние што беа поврзани со соодветната датотека. Ова значеше дека со кликнување на копче во Firefox може да се активираат мегабајти податоци за запишување на магнетен диск, што може да потрае многу секунди. Решението на проблемот, колку што разбрав на овој материјалот требаше да ја префрли работата со базата на податоци на асинхрони задачи во заднина. Ова значи дека Firefox претходно имплементираше построги барања за складирање отколку што навистина беше потребно, а карактеристиките на датотечниот систем ext3 само го влошија овој проблем.

Вториот проблем се случи во 2009 година. Потоа, по падот на системот, корисниците на новиот датотечен систем ext4 се соочија со фактот дека многу новосоздадени датотеки имаат нула должина, но тоа не се случи со постариот датотечен систем ext3. Во претходниот пасус, зборував за тоа како ext3 исфрли премногу податоци на дискот, што многу ги забави работите. fsync(). За да се подобри ситуацијата, во ext4, само оние валкани страници што се релевантни за одредена датотека се префрлаат на дискот. И податоците од другите датотеки остануваат во меморијата многу подолго време отколку со ext3. Ова е направено за да се подобрат перформансите (стандардно, податоците остануваат во оваа состојба 30 секунди, можете да го конфигурирате ова користејќи dirty_expire_centisecs; тука Можете да најдете дополнителни материјали за ова). Ова значи дека голема количина на податоци може неповратно да се изгубат по дефект. Решението за овој проблем е да се користи fsync() во апликации кои треба да обезбедат стабилно складирање на податоци и да ги заштитат колку што е можно повеќе од последиците од неуспесите. Функција fsync() работи многу поефикасно кога се користи ext4 отколку кога се користи ext3. Недостаток на овој пристап е што неговата употреба, како и досега, го забавува извршувањето на некои операции, како што е инсталирањето програми. Погледнете детали за ова тука и тука.

Третиот проблем во врска со fsync(), потекнува од 2018 година. Потоа, во рамките на проектот PostgreSQL, беше откриено дека ако функцијата fsync() наидува на грешка, ги означува „валканите“ страници како „чисти“. Како резултат на тоа, следните повици fsync() Тие не прават ништо со такви страници. Поради ова, изменетите страници се зачувуваат во меморијата и никогаш не се запишуваат на дискот. Ова е вистинска катастрофа, бидејќи апликацијата ќе мисли дека некои податоци се запишани на дискот, но всушност тоа нема да биде. Вакви неуспеси fsync() се ретки, апликацијата во такви ситуации не може да направи речиси ништо за да се избори со проблемот. Деновиве, кога тоа ќе се случи, PostgreSQL и другите апликации паѓаат. Тука, во материјалот „Дали апликациите можат да закрепнат од дефекти на fsync?“, овој проблем е детално истражен. Во моментов најдоброто решение за овој проблем е да се користи Direct I/O со знамето O_SYNC или со знаме O_DSYNC. Со овој пристап, системот ќе пријави грешки што може да се појават за време на одредени операции за запишување, но овој пристап бара апликацијата да управува со баферите самата. Прочитајте повеќе за ова тука и тука.

Отворање датотеки со помош на знаменцата O_SYNC и O_DSYNC

Да се ​​вратиме на дискусијата за механизмите на Linux кои обезбедуваат стабилно складирање на податоци. Имено, зборуваме за користење на знамето O_SYNC или знаме O_DSYNC кога отворате датотеки користејќи системски повик отворено (). Со овој пристап, секоја операција за запишување податоци се изведува како по секоја команда write() системот добива соодветни команди fsync() и fdatasync(). Во Спецификации на POSIX ова се нарекува „Синхронизирано I/O File Integrity Completion“ и „Data Integrity Completion“. Главната предност на овој пристап е што за да се обезбеди интегритет на податоците, потребно е само да остварите еден системски повик, наместо два (на пример - write() и fdatasync()). Главниот недостаток на овој пристап е што сите записи со користење на соодветниот дескриптор на датотеката ќе бидат синхронизирани, што може да ја ограничи способноста за структурирање на кодот на апликацијата.

Користење на Direct I/O со знаменцето O_DIRECT

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

Се испостави дека датотечниот систем XFS неодамна додаде „брза патека“ за O_DIRECT|O_DSYNC-снимање на податоци. Ако некој блок се препишува со користење O_DIRECT|O_DSYNC, а потоа XFS, наместо да го испушти кешот, ќе ја изврши командата за пишување FUA доколку уредот ја поддржува. Го потврдив ова користејќи ја алатката blktrace на систем Linux 5.4/Ubuntu 20.04. Овој пристап треба да биде поефикасен, бидејќи кога се користи, минимална количина на податоци се запишува на дискот и се користи една операција, наместо две (пишување и испирање на кешот). Најдов линк до лепенка 2018 кернел, кој го имплементира овој механизам. Има дискусија за примена на оваа оптимизација на други датотечни системи, но колку што знам, XFS е единствениот датотечен систем што го поддржува ова досега.

sync_file_range() функција

Линукс има системски повик sync_file_range(), што ви овозможува да измиете само дел од датотеката на дискот, наместо целата датотека. Овој повик иницира асинхроно испирање на податоци и не чека да заврши. Но, во сертификатот sync_file_range() се вели дека тимот е „многу опасен“. Не се препорачува да се користи. Карактеристики и опасности sync_file_range() многу добро опишано во ова материјал. Поточно, се чини дека овој повик користи RocksDB за да контролира кога кернелот фрла валкани податоци на дискот. Но, во исто време, за да се обезбеди стабилно складирање на податоци, исто така се користи fdatasync(). Во код RocksDB има неколку интересни коментари на оваа тема. На пример, се чини дека повикот sync_file_range() Кога користите ZFS, не ги исфрла податоците на дискот. Искуството ми кажува дека кодот што ретко се користи веројатно содржи грешки. Затоа, би ве советувал да не го користите овој системски повик освен ако е апсолутно неопходно.

Системски повици кои помагаат да се обезбеди трајност на податоците

Дојдов до заклучок дека постојат три пристапи кои можат да се користат за извршување на I/O операции кои обезбедуваат постојаност на податоците. Сите тие бараат повик за функција 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%) подобрување на перформансите. Особено, ова може да се случи со дискови AWS EBS (ова се неофицијални податоци, не можев да потврдам). Истото важи и за складирање GCP постојан диск (и ова е веќе официјална информација, потврдена со тестови). И други експерти го направија истото набљудување, поврзани со различни дискови.
2. Колку помалку системски повици, толку се повисоки перформансите (добивката може да биде околу 5%). Изгледа како предизвик open() со знаме O_DSYNC или јавете се pwritev2() со знаме RWF_SYNC побрзо од повик fdatasync(). Се сомневам дека поентата овде е дека овој пристап игра улога во фактот што треба да се извршат помалку системски повици за да се реши истиот проблем (еден повик наместо два). Но, разликата во перформансите е многу мала, па можете целосно да ја игнорирате и да искористите нешто во апликацијата што нема да ја комплицира нејзината логика.

Доколку ве интересира темата за одржливо складирање податоци, еве неколку корисни материјали:

• I/O Пристапни методи — преглед на основите на влезно/излезните механизми.
• Обезбедување на податоците да стигнат до дискот — приказна за тоа што се случува со податоците на патот од апликацијата до дискот.
• Кога треба да го синхронизирате директориумот што содржи - одговорот на прашањето кога да се користи fsync() за директориуми. Да го ставиме ова накратко, излегува дека треба да го направите ова кога креирате нова датотека, а причината за оваа препорака е што во Linux може да има многу референци за истата датотека.
• SQL Server на Linux: FUA Internals — тука е опис на тоа како постојаното складирање податоци се имплементира во SQL Server на платформата Linux. Овде има неколку интересни споредби помеѓу системските повици на Windows и Linux. Речиси сум сигурен дека благодарение на овој материјал научив за FUA оптимизацијата на XFS.

Дали сте изгубиле податоци за кои мислевте дека се безбедно зачувани на диск?

Извор: www.habr.com