Устойчиво съхранение на данни и API за Linux файлове

Аз, изследвайки стабилността на съхранението на данни в облачни системи, реших да се тествам, за да се уверя, че разбирам основните неща. аз започна с четене на спецификацията на NVMe за да разберем какви гаранции по отношение на устойчивостта на данните (т.е. гаранции, че данните ще бъдат налични след повреда на системата), ни дават NMVe дискове. Направих следните основни заключения: трябва да считате данните за повредени от момента, в който е дадена командата за запис на данни, и до момента, в който са записани на носителя за съхранение. В повечето програми обаче системните повиквания се използват доста безопасно за запис на данни.

В тази статия изследвам механизмите за постоянство, осигурени от файловите API на Linux. Изглежда, че тук всичко трябва да е просто: програмата извиква командата write(), и след като операцията на тази команда приключи, данните ще бъдат сигурно съхранени на диска. Но write() копира само данните на приложението в кеша на ядрото, разположен в RAM. За да се принуди системата да записва данни на диск, трябва да се използват някои допълнителни механизми.

Като цяло този материал е набор от бележки, свързани с това, което съм научил по тема, която ме интересува. Ако говорим накратко за най-важното, се оказва, че за да организирате устойчиво съхранение на данни, трябва да използвате командата fdatasync() или отваряйте файлове с флаг O_DSYNC. Ако се интересувате да научите повече за това какво се случва с данните по пътя от кода към диска, разгледайте това статия.

Характеристики на използването на функцията write().

Системно обаждане write() определени в стандарта IEEE POSIX като опит за запис на данни във файлов дескриптор. След успешно приключване на работата write() операциите за четене на данни трябва да връщат точно байтовете, които са били записани преди това, като правят това дори ако данните са достъпни от други процеси или нишки (тук съответния раздел на стандарта POSIX). Тук, в раздела за взаимодействието на нишки с нормални файлови операции има бележка, която казва, че ако две нишки извикват тези функции, тогава всяко повикване трябва или да види всички посочени последствия, до които води изпълнението на другото повикване, или изобщо не виждам никакви последствия. Това води до заключението, че всички файлови I/O операции трябва да поддържат заключване на ресурса, върху който се работи.

Означава ли това, че операцията 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 файлове“ и „Завършване на интегритета на данните“. Основното предимство на този подход е, че трябва да се изпълни само едно системно извикване, за да се гарантира целостта на данните, а не две (например − write() и fdatasync()). Основният недостатък на този подход е, че всички операции за запис, използващи съответния файлов дескриптор, ще бъдат синхронизирани, което може да ограничи възможността за структуриране на кода на приложението.

Използване на Direct I/O с флага O_DIRECT

Системно обаждане open() поддържа знамето O_DIRECT, който е предназначен да заобикаля кеша на операционната система, да извършва I / O операции, взаимодействайки директно с диска. Това в много случаи означава, че командите за запис, издадени от програмата, ще бъдат директно преведени в команди, насочени към работа с диска. Но като цяло този механизъм не е заместител на функциите fsync() или fdatasync(). Факт е, че самият диск може забавяне или кеш подходящи команди за запис на данни. И, още по-лошо, в някои специални случаи I / O операциите се извършват при използване на флага 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().

Linux има системно извикване 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 съдържащата директория - отговорът на въпроса кога да се кандидатства fsync() за директории. Накратко, оказва се, че трябва да направите това, когато създавате нов файл и причината за тази препоръка е, че в Linux може да има много препратки към един и същ файл.
• SQL Server на Linux: FUA вътрешни - тук е описание на това как постоянното съхранение на данни е реализирано в SQL Server на платформата Linux. Тук има някои интересни сравнения между системните извиквания на Windows и Linux. Почти съм сигурен, че благодарение на този материал научих за FUA оптимизацията на XFS.

Губили ли сте някога данни, които смятате, че са сигурно съхранени на диск?

Източник: www.habr.com