{"id":98090,"date":"2020-10-24T02:42:38","date_gmt":"2020-10-24T00:42:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux"},"modified":"2020-11-18T00:58:48","modified_gmt":"2020-11-17T22:58:48","slug":"ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"Trval\u00e9 ukl\u00e1d\u00e1n\u00ed dat a souborov\u00e1 API pro Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

J\u00e1, p\u0159i zkoum\u00e1n\u00ed trvanlivosti ukl\u00e1d\u00e1n\u00ed dat v cloudov\u00fdch syst\u00e9mech, jsem se rozhodl ov\u011b\u0159it si, zda rozum\u00edm z\u00e1kladn\u00edm v\u011bcem. J\u00e1 jsem za\u010dal \u010dten\u00edm specifikace NVMe<\/a><\/noindex> , abych pochopil, jak\u00e9 z\u00e1ruky t\u00fdkaj\u00edc\u00ed se trval\u00e9ho ukl\u00e1d\u00e1n\u00ed dat (to znamen\u00e1 \u2013 z\u00e1ruky, \u017ee data budou dostupn\u00e1 po selh\u00e1n\u00ed syst\u00e9mu) n\u00e1m NVMe disky poskytuj\u00ed. U\u010dinil jsem n\u00e1sleduj\u00edc\u00ed hlavn\u00ed z\u00e1v\u011bry: je t\u0159eba pova\u017eovat data za po\u0161kozen\u00e1 od okam\u017eiku, kdy byla zad\u00e1na p\u0159\u00edkaz k z\u00e1pisu dat, a do okam\u017eiku, kdy skon\u010d\u00ed jejich z\u00e1pis na m\u00e9dium. Nicm\u00e9n\u011b v v\u011bt\u0161in\u011b program\u016f pro z\u00e1pis dat se zcela b\u011b\u017en\u011b pou\u017e\u00edvaj\u00ed syst\u00e9mov\u00e9 vol\u00e1n\u00ed.<\/p>\n

V tomto materi\u00e1lu zkoum\u00e1m mechanismy trval\u00e9ho ukl\u00e1d\u00e1n\u00ed dat poskytovan\u00e9 souborov\u00fdmi API pro Linux. Zd\u00e1 se, \u017ee by to m\u011blo b\u00fdt jednoduch\u00e9: program vyvol\u00e1 p\u0159\u00edkaz write()<\/code>, a po dokon\u010den\u00ed t\u00e9to operace budou data spolehliv\u011b ulo\u017eena na disku. Ale write()<\/code> pouze zkop\u00edruje data aplikace do j\u00e1drov\u00e9ho cache um\u00edst\u011bn\u00e9ho v opera\u010dn\u00ed pam\u011bti. Aby bylo mo\u017en\u00e9 donutit syst\u00e9m k z\u00e1pisu dat na disk, je t\u0159eba pou\u017e\u00edt n\u011bkter\u00e9 dal\u0161\u00ed mechanismy.<\/p>\n

\"Trval\u00e9<\/a><\/noindex><\/p>\n

Celkov\u011b tento materi\u00e1l p\u0159edstavuje soubor pozn\u00e1mek o tom, co jsem se dozv\u011bd\u011bl o t\u00e9matu, kter\u00e9 m\u011b zaj\u00edm\u00e1. Pokud bych m\u011bl velmi stru\u010dn\u011b shrnout to nejd\u016fle\u017eit\u011bj\u0161\u00ed, pak plat\u00ed, \u017ee pro organizaci trval\u00e9ho ukl\u00e1d\u00e1n\u00ed dat je t\u0159eba pou\u017e\u00edvat p\u0159\u00edkaz fdatasync()<\/code> nebo otev\u00edrat soubory s p\u0159\u00edznakem O_DSYNC<\/code>. Pokud v\u00e1s zaj\u00edmaj\u00ed podrobnosti o tom, co se d\u011bje s daty na cest\u011b od programov\u00e9ho k\u00f3du k disku, pod\u00edvejte se na tento<\/a><\/noindex> \u010dl\u00e1nek.
\n<\/a><\/noindex><\/p>\n

Zvl\u00e1\u0161tnosti pou\u017eit\u00ed funkce write()<\/h2>\n

\nSyst\u00e9mov\u00e9 vol\u00e1n\u00ed write()<\/code> je definov\u00e1no v standardu IEEE POSIX<\/a><\/noindex> jako pokus o z\u00e1pis dat do souborov\u00e9ho deskriptoru. Po \u00fasp\u011b\u0161n\u00e9m dokon\u010den\u00ed write()<\/code> operace by m\u011bly vr\u00e1tit p\u0159esn\u011b ty byty, kter\u00e9 byly p\u0159edt\u00edm zaps\u00e1ny, a to i v p\u0159\u00edpad\u011b, \u017ee k dat\u016fm p\u0159istupuj\u00ed jin\u00e9 procesy nebo vl\u00e1kna (tady je<\/a><\/noindex> p\u0159\u00edslu\u0161n\u00e1 \u010d\u00e1st standardu POSIX). Zde<\/a><\/noindex>, v sekci, v\u011bnovan\u00e9 interakci vl\u00e1ken s b\u011b\u017en\u00fdmi souborov\u00fdmi operacemi, je pozn\u00e1mka, v n\u00ed\u017e se uv\u00e1d\u00ed, \u017ee pokud ka\u017ed\u00fd z dvou vl\u00e1ken vol\u00e1 tyto funkce, mus\u00ed ka\u017ed\u00e9 vol\u00e1n\u00ed vid\u011bt bu\u010f v\u0161echny vyzna\u010den\u00e9 d\u016fsledky vypl\u00fdvaj\u00edc\u00ed z prov\u00e1d\u011bn\u00ed jin\u00e9ho vol\u00e1n\u00ed, nebo v\u016fbec \u017e\u00e1dn\u00e9 d\u016fsledky. To umo\u017e\u0148uje doj\u00edt k z\u00e1v\u011bru, \u017ee v\u0161echny operace vstupu\/v\u00fdstupu p\u0159i pr\u00e1ci se soubory mus\u00ed dr\u017eet z\u00e1mek na zdroji, se kter\u00fdm pracuj\u00ed.<\/p>\n

Znamen\u00e1 to, \u017ee operace write()<\/code> je atomick\u00e1? Z technick\u00e9ho hlediska - ano. Operace \u010dten\u00ed dat mus\u00ed vracet bu\u010f v\u0161e, nebo nic z toho, co bylo zaps\u00e1no pomoc\u00ed write()<\/code>. Ale operace write()<\/code>, dle standardu, nemus\u00ed nutn\u011b kon\u010dit t\u00edm, \u017ee zap\u00ed\u0161e v\u0161e, co j\u00ed bylo nab\u00eddnuto k z\u00e1pisu. Je j\u00ed dovoleno prov\u00e9st z\u00e1pis pouze \u010d\u00e1sti dat. Nap\u0159\u00edklad, m\u016f\u017eeme m\u00edt dv\u011b vl\u00e1kna, z nich\u017e ka\u017ed\u00e9 p\u0159ipojuje 1024 bajt\u016f k souboru popsan\u00e9mu stejn\u00fdm souborov\u00fdm descriptor. Z hlediska standardu je akceptovateln\u00fdm v\u00fdsledkem, kdy\u017e ka\u017ed\u00e1 z operac\u00ed z\u00e1pisu m\u016f\u017ee p\u0159ipojit k souboru pouze jeden bajt. Tyto operace z\u016fstanou atom\u00e1rn\u00ed, ale po jejich dokon\u010den\u00ed budou data, kter\u00e1 byla zaps\u00e1na do souboru, prom\u00edch\u00e1na. Tady<\/a><\/noindex> je velmi zaj\u00edmav\u00e1 diskuse na toto t\u00e9ma na Stack Overflow.<\/p>\n

Funkce fsync() a fdatasync()<\/h2>\n

\nNejjednodu\u0161\u0161\u00ed zp\u016fsob, jak p\u0159ev\u00e9st data na disk, je vol\u00e1n\u00ed funkce fsync()<\/a><\/noindex>. Tato funkce po\u017eaduje od opera\u010dn\u00edho syst\u00e9mu p\u0159enos v\u0161ech modifikovan\u00fdch blok\u016f z cache na disk. Zahrnuje to i v\u0161echna metadata souboru (\u010das p\u0159\u00edstupu, \u010das modifikace souboru atd.). Domn\u00edv\u00e1m se, \u017ee pot\u0159eba t\u011bchto metadat vznik\u00e1 z\u0159\u00eddka, tak\u017ee pokud v\u00edte, \u017ee pro v\u00e1s nejsou d\u016fle\u017eit\u00e1, m\u016f\u017eete pou\u017e\u00edvat funkci fdatasync()<\/code>. V n\u00e1pov\u011bd\u011b<\/a><\/noindex> o fdatasync()<\/code> se uv\u00e1d\u00ed, \u017ee b\u011bhem pr\u00e1ce t\u00e9to funkce se ukl\u00e1d\u00e1 na disk takov\u00fd objem metadat, kter\u00fd \"je nezbytn\u00fd pro spr\u00e1vn\u00e9 proveden\u00ed n\u00e1sleduj\u00edc\u00edch operac\u00ed \u010dten\u00ed dat\". A to je p\u0159esn\u011b to, co zaj\u00edm\u00e1 v\u011bt\u0161inu aplikac\u00ed.<\/p>\n

Jedn\u00edm z probl\u00e9m\u016f, kter\u00e9 mohou nastat, je, \u017ee tyto mechanismy nezaru\u010duj\u00ed, \u017ee soubor bude mo\u017en\u00e9 naj\u00edt po p\u0159\u00edpadn\u00e9m selh\u00e1n\u00ed. Zejm\u00e9na kdy\u017e se vytv\u00e1\u0159\u00ed nov\u00fd soubor, je nutn\u00e9 zavolat fsync()<\/code> pro adres\u00e1\u0159, kter\u00fd jej obsahuje. Jinak se po chyb\u011b m\u016f\u017ee st\u00e1t, \u017ee tento soubor neexistuje. D\u016fvodem je, \u017ee v UNIXu, kv\u016fli pou\u017e\u00edv\u00e1n\u00ed tvrd\u00fdch odkaz\u016f, m\u016f\u017ee soubor existovat v n\u011bkolika adres\u00e1\u0159\u00edch. Proto p\u0159i vyvol\u00e1n\u00ed fsync()<\/code> pro soubor neexistuje \u017e\u00e1dn\u00fd zp\u016fsob, jak zjistit, o kter\u00e9 konkr\u00e9tn\u00ed adres\u00e1\u0159e je tak\u00e9 t\u0159eba vypr\u00e1zdnit na disk (tady<\/a><\/noindex> o tom se m\u016f\u017eete do\u010d\u00edst podrobn\u011bji). Zd\u00e1 se, \u017ee souborov\u00fd syst\u00e9m ext4 je schopen automaticky<\/a><\/noindex> aplikovat fsync()<\/code> na adres\u00e1\u0159e obsahuj\u00edc\u00ed odpov\u00eddaj\u00edc\u00ed soubory, ale v p\u0159\u00edpad\u011b jin\u00fdch souborov\u00fdch syst\u00e9m\u016f tomu tak b\u00fdt nemus\u00ed.<\/p>\n

Tento mechanismus m\u016f\u017ee b\u00fdt r\u016fzn\u011b implementov\u00e1n v r\u016fzn\u00fdch souborov\u00fdch syst\u00e9mech. Pou\u017eil jsem blktrace<\/a><\/noindex> k zji\u0161t\u011bn\u00ed, jak\u00e9 diskov\u00e9 operace jsou pou\u017e\u00edv\u00e1ny v souborov\u00fdch syst\u00e9mech ext4 a XFS. Ob\u011b vyd\u00e1vaj\u00ed b\u011b\u017en\u00e9 p\u0159\u00edkazy pro z\u00e1pis na disk jak pro obsah soubor\u016f, tak pro protokol souborov\u00e9ho syst\u00e9mu, vypr\u00e1zd\u0148uj\u00ed mezipam\u011b\u0165 a kon\u010d\u00ed \u010dinnost proveden\u00edm FUA z\u00e1pisu (Force Unit Access, z\u00e1pis dat p\u0159\u00edmo na disk, obch\u00e1zen\u00edm mezipam\u011bti) do protokolu. Pravd\u011bpodobn\u011b tak \u010din\u00ed, aby potvrdily proveden\u00ed operace. Na disc\u00edch, kter\u00e9 FUA nepodporuj\u00ed, to vyvol\u00e1v\u00e1 dva vypr\u00e1zdn\u011bn\u00ed mezipam\u011bti. Moje experimenty uk\u00e1zaly, \u017ee fdatasync()<\/code> o n\u011bco rychleji fsync()<\/code>. N\u00e1stroj blktrace<\/code> ukazuje, \u017ee fdatasync()<\/code> obvykle zapisuje na disk m\u00e9n\u011b dat (v ext4 fsync()<\/code> zapisuje 20 KiB, a fdatasync()<\/code> \u2014 16 KiB). Krom\u011b toho jsem zjistil, \u017ee XFS je o n\u011bco rychlej\u0161\u00ed ne\u017e ext4. A zde s pomoc\u00ed blktrace<\/code> se mi poda\u0159ilo zjistit, \u017ee fdatasync()<\/code> vypr\u00e1zd\u0148uje na disk m\u00e9n\u011b dat (4 KiB v XFS).<\/p>\n

Nejednozna\u010dn\u00e9 situace vznikaj\u00edc\u00ed p\u0159i pou\u017e\u00edv\u00e1n\u00ed fsync()<\/h2>\n

\nMohu si vzpomenout na t\u0159i nejednozna\u010dn\u00e9 situace, kter\u00e9 se t\u00fdkaj\u00ed fsync()<\/code>, se kter\u00fdmi jsem se setkal v praxi.<\/p>\n

Prvn\u00ed takov\u00fd p\u0159\u00edpad nastal v roce 2008. Tehdy rozhran\u00ed Firefox 3 \u201ezamrzlo\u201c, pokud se prov\u00e1d\u011bl z\u00e1pis na disk velk\u00e9ho mno\u017estv\u00ed soubor\u016f. Probl\u00e9m spo\u010d\u00edval v tom, \u017ee v implementaci rozhran\u00ed pro ulo\u017een\u00ed informac\u00ed o jeho stavu byla pou\u017eita datab\u00e1ze SQLite. Po ka\u017ed\u00e9 zm\u011bn\u011b, kter\u00e1 se v rozhran\u00ed odehr\u00e1la, byla vyvol\u00e1na funkce fsync()<\/code>, co\u017e zaji\u0161\u0165ovalo dobr\u00e9 z\u00e1ruky trval\u00e9ho ulo\u017een\u00ed dat. Ve souborov\u00e9m syst\u00e9mu ext3, kter\u00fd byl tehdy pou\u017e\u00edv\u00e1n, funkce fsync()<\/code> ukl\u00e1dala na disk v\u0161echny \"\u0161pinav\u00e9\" str\u00e1nky v syst\u00e9mu, a ne jen ty, kter\u00e9 se vztahovaly k p\u0159\u00edslu\u0161n\u00e9mu souboru. To znamenalo, \u017ee kliknut\u00ed na tla\u010d\u00edtko v prohl\u00ed\u017ee\u010di Firefox mohlo iniciovat z\u00e1pis megabajt\u016f dat na magnetick\u00fd disk, co\u017e mohlo trvat mnoho sekund. \u0158e\u0161en\u00ed probl\u00e9mu, jak jsem pochopil z tohoto<\/a><\/noindex> materi\u00e1lu, spo\u010d\u00edvalo v p\u0159esunut\u00ed pr\u00e1ce s datab\u00e1z\u00ed do asynchronn\u00edch \u00faloh na pozad\u00ed. To znamen\u00e1, \u017ee d\u0159\u00edve v prohl\u00ed\u017ee\u010di Firefox byla zavedena p\u0159\u00edsn\u011bj\u0161\u00ed pravidla pro trvanlivost ukl\u00e1d\u00e1n\u00ed dat, ne\u017e bylo skute\u010dn\u011b pot\u0159eba, a specifika souborov\u00e9ho syst\u00e9mu ext3 tuto problematiku je\u0161t\u011b zhor\u0161ila.<\/p>\n

Druh\u00e1 nesrovnalost nastala v roce 2009. Tehdy, po p\u00e1du syst\u00e9mu, u\u017eivatel\u00e9 nov\u00e9ho souborov\u00e9ho syst\u00e9mu ext4 \u010delili probl\u00e9mu, \u017ee mnoho ned\u00e1vno vytvo\u0159en\u00fdch soubor\u016f m\u00e1 nulovou d\u00e9lku, co\u017e se u star\u0161\u00edho souborov\u00e9ho syst\u00e9mu ext3 nestalo. V p\u0159edchoz\u00edm odstavci jsem zmi\u0148oval, \u017ee ext3 ukl\u00e1dala na disk p\u0159\u00edli\u0161 mnoho dat, co\u017e v\u00fdrazn\u011b zpomalovalo fsync()<\/code>jeho v\u00fdkon. Aby se situace zlep\u0161ila, v ext4 se na disk ukl\u00e1daj\u00ed pouze ty \"\u0161pinav\u00e9\" str\u00e1nky, kter\u00e9 se vztahuj\u00ed k ur\u010dit\u00e9mu souboru. Data ostatn\u00edch soubor\u016f z\u016fst\u00e1vaj\u00ed v pam\u011bti mnohem d\u00e9le, ne\u017e bylo mo\u017en\u00e9 p\u0159i pou\u017eit\u00ed ext3. To bylo provedeno za \u00fa\u010delem zlep\u0161en\u00ed v\u00fdkonu (ve v\u00fdchoz\u00edm stavu data z\u016fst\u00e1vaj\u00ed v tomto stavu 30 sekund, tento \u010das lze nastavit pomoc\u00ed dirty_expire_centisecs<\/a><\/noindex>; tady<\/a><\/noindex> o tom si m\u016f\u017eete p\u0159e\u010d\u00edst v\u00edce). To znamen\u00e1, \u017ee velk\u00e9 objemy dat mohou b\u00fdt nen\u00e1vratn\u011b ztraceny po p\u00e1du. \u0158e\u0161en\u00edm tohoto probl\u00e9mu je pou\u017eit\u00ed fsync()<\/code> v aplikac\u00edch, kter\u00e9 pot\u0159ebuj\u00ed zajistit trval\u00e9 ukl\u00e1d\u00e1n\u00ed dat a maxim\u00e1ln\u011b je chr\u00e1nit p\u0159ed d\u016fsledky v\u00fdpadk\u016f. Funkce fsync()<\/code> funguje p\u0159i pou\u017eit\u00ed ext4 mnohem efektivn\u011bji ne\u017e p\u0159i pou\u017eit\u00ed ext3. Nev\u00fdhodou tohoto p\u0159\u00edstupu v\u0161ak z\u016fst\u00e1v\u00e1, \u017ee jeho pou\u017eit\u00ed, stejn\u011b jako d\u0159\u00edve, zpomaluje prov\u00e1d\u011bn\u00ed n\u011bkter\u00fdch operac\u00ed, jako je instalace program\u016f. Podrobnosti o tom naleznete zde<\/a><\/noindex> a zde<\/a><\/noindex>.<\/p>\n

T\u0159et\u00ed probl\u00e9m, kter\u00fd se t\u00fdk\u00e1 fsync()<\/code>, vznikl v roce 2018. Tehdy, v r\u00e1mci projektu PostgreSQL, bylo zji\u0161t\u011bno, \u017ee pokud funkce fsync()<\/code> naraz\u00ed na chybu, ozna\u010duje \"\u0161pinav\u00e9\" str\u00e1nky jako \"\u010dist\u00e9\". V d\u016fsledku toho n\u00e1sleduj\u00edc\u00ed vol\u00e1n\u00ed fsync()<\/code> S takov\u00fdmi str\u00e1nkami se nic ned\u011bl\u00e1. Z tohoto d\u016fvodu jsou upraven\u00e9 str\u00e1nky uchov\u00e1v\u00e1ny v pam\u011bti a nikdy nejsou zapisov\u00e1ny na disk. To je skute\u010dn\u00e1 katastrofa, proto\u017ee aplikace si bude myslet, \u017ee n\u011bjak\u00e1 data byla zaps\u00e1na na disk, ale ve skute\u010dnosti to tak nebude. Takov\u00e9 selh\u00e1n\u00ed fsync()<\/code> se st\u00e1v\u00e1 z\u0159\u00eddka, aplikace v takov\u00fdch situac\u00edch skoro nic nem\u016f\u017ee ud\u011blat pro \u0159e\u0161en\u00ed probl\u00e9mu. Dnes, kdy\u017e se to stane, PostgreSQL a jin\u00e9 aplikace havaruj\u00ed. Zde<\/a><\/noindex>, v materi\u00e1lu \"Can Applications Recover from fsync Failures?\" je tento probl\u00e9m zkoum\u00e1n podrobn\u011b. V sou\u010dasn\u00e9 dob\u011b je nejlep\u0161\u00edm \u0159e\u0161en\u00edm tohoto probl\u00e9mu pou\u017eit\u00ed Direct I\/O s p\u0159\u00edznakem O_SYNC<\/code> nebo s p\u0159\u00edznakem O_DSYNC<\/code>. P\u0159i tomto p\u0159\u00edstupu syst\u00e9m ozn\u00e1m\u00ed chyby, kter\u00e9 mohou vzniknout p\u0159i prov\u00e1d\u011bn\u00ed konkr\u00e9tn\u00edch operac\u00ed z\u00e1pisu dat, ale tento p\u0159\u00edstup vy\u017eaduje, aby aplikace spravovala bu\u010f samotn\u00e9 vyrovn\u00e1vac\u00ed pam\u011bti. Podrobnosti o tom naleznete zde<\/a><\/noindex> a zde<\/a><\/noindex>.<\/p>\n

Otev\u0159en\u00ed soubor\u016f s pou\u017eit\u00edm p\u0159\u00edznak\u016f O_SYNC a O_DSYNC<\/h2>\n

\nVra\u0165me se k diskusi o mechanismech Linuxu, kter\u00e9 zaji\u0161\u0165uj\u00ed trval\u00e9 ulo\u017een\u00ed dat. Konkr\u00e9tn\u011b se jedn\u00e1 o pou\u017eit\u00ed p\u0159\u00edznaku O_SYNC<\/code> nebo p\u0159\u00edznaku O_DSYNC<\/code> p\u0159i otev\u00edr\u00e1n\u00ed soubor\u016f pomoc\u00ed syst\u00e9mov\u00e9ho vol\u00e1n\u00ed open()<\/a><\/noindex>. P\u0159i tomto p\u0159\u00edstupu se ka\u017ed\u00e1 operace z\u00e1pisu dat prov\u00e1d\u00ed tak, jako by po ka\u017ed\u00e9m p\u0159\u00edkazu write()<\/code> syst\u00e9mu byly d\u00e1ny p\u0159\u00edslu\u0161n\u00e9 p\u0159\u00edkazy fsync()<\/code> a fdatasync()<\/code>. V specifikace POSIX<\/a><\/noindex> se naz\u00fdv\u00e1 \u201eSynchronized I\/O File Integrity Completion\u201c a \u201eData Integrity Completion\u201c. Hlavn\u00ed v\u00fdhodou tohoto p\u0159\u00edstupu je, \u017ee k zaji\u0161t\u011bn\u00ed integrity dat je t\u0159eba prov\u00e9st pouze jeden syst\u00e9mov\u00fd hovor, a ne dva (nap\u0159\u00edklad \u2014 write()<\/code> a fdatasync()<\/code>). Hlavn\u00ed nev\u00fdhodou tohoto p\u0159\u00edstupu je, \u017ee v\u0161echny operace z\u00e1pisu vyu\u017e\u00edvaj\u00edc\u00ed odpov\u00eddaj\u00edc\u00ed popisova\u010d souboru budou synchronizov\u00e1ny, co\u017e m\u016f\u017ee omezit mo\u017enosti strukturov\u00e1n\u00ed k\u00f3du aplikace.<\/p>\n

Pou\u017eit\u00ed Direct I\/O s p\u0159\u00edznakem O_DIRECT<\/h2>\n

\nSyst\u00e9mov\u00e9 vol\u00e1n\u00ed open()<\/code> podporuje p\u0159\u00edznak O_DIRECT<\/code>, kter\u00fd je ur\u010den k tomu, aby, obch\u00e1zel cache opera\u010dn\u00edho syst\u00e9mu, prov\u00e1d\u011bl operace vstupu a v\u00fdstupu p\u0159\u00edmo s diskem. To ve v\u011bt\u0161in\u011b p\u0159\u00edpad\u016f znamen\u00e1, \u017ee z\u00e1pisov\u00e9 p\u0159\u00edkazy vydan\u00e9 programem budou p\u0159\u00edmo p\u0159ekl\u00e1d\u00e1ny na p\u0159\u00edkazy ur\u010den\u00e9 pro pr\u00e1ci s diskem. Ale obecn\u011b, tento mechanismus nen\u00ed n\u00e1hradou funkc\u00ed fsync()<\/code> nebo fdatasync()<\/code>. Skute\u010dnost je takov\u00e1, \u017ee samotn\u00fd disk m\u016f\u017ee odlo\u017eit nebo ke\u0161ovat<\/a><\/noindex> odpov\u00eddaj\u00edc\u00ed p\u0159\u00edkazy pro z\u00e1pis dat. A co je hor\u0161\u00ed, v n\u011bkter\u00fdch speci\u00e1ln\u00edch p\u0159\u00edpadech se operace I\/O prov\u00e1d\u011bn\u00e9 s pou\u017eit\u00edm flagu O_DIRECT<\/code>, se p\u0159en\u00e1\u0161ej\u00ed<\/a><\/noindex> na tradi\u010dn\u00ed vyrovn\u00e1vac\u00ed operace. Nejjednodu\u0161\u0161\u00ed zp\u016fsob, jak tento probl\u00e9m vy\u0159e\u0161it, je pou\u017e\u00edt pro otev\u0159en\u00ed soubor\u016f tak\u00e9 flag O_DSYNC<\/code>, co\u017e znamen\u00e1, \u017ee za ka\u017edou z\u00e1pisovou operac\u00ed n\u00e1sleduje vol\u00e1n\u00ed fdatasync()<\/code>.<\/p>\n

Uk\u00e1zalo se, \u017ee do souborov\u00e9ho syst\u00e9mu XFS byla ned\u00e1vno p\u0159id\u00e1na \"rychl\u00e1 cesta\" pro O_DIRECT|O_DSYNC<\/code>-z\u00e1pis dat. Pokud p\u0159episuj\u00ed blok s pou\u017eit\u00edm O_DIRECT|O_DSYNC<\/code>, pak XFS m\u00edsto vypr\u00e1zdn\u011bn\u00ed cache provede p\u0159\u00edkaz FUA-z\u00e1pisu, pokud to za\u0159\u00edzen\u00ed podporuje. Ov\u011b\u0159il jsem to pomoc\u00ed n\u00e1stroje blktrace<\/code> v syst\u00e9mu Linux 5.4\/Ubuntu 20.04. Tento p\u0159\u00edstup by m\u011bl b\u00fdt efektivn\u011bj\u0161\u00ed, proto\u017ee p\u0159i jeho pou\u017eit\u00ed se na disk zap\u00ed\u0161e minim\u00e1ln\u00ed mno\u017estv\u00ed dat a prov\u00e1d\u00ed se pouze jedna operace, nikoli dv\u011b (z\u00e1pis a vypr\u00e1zdn\u011bn\u00ed cache). Na\u0161el jsem odkaz na patch<\/a><\/noindex> j\u00e1dra z roku 2018, ve kter\u00e9m je tento mechanismus realizov\u00e1n. Obsahuje diskusi o aplikaci t\u00e9to optimalizace i v jin\u00fdch souborov\u00fdch syst\u00e9mech, ale co v\u00edm, XFS je zat\u00edm jedin\u00fd souborov\u00fd syst\u00e9m, kter\u00fd to podporuje.<\/p>\n

Funkce sync_file_range()<\/h2>\n

\nV Linuxu existuje syst\u00e9mov\u00e9 vol\u00e1n\u00ed sync_file_range()<\/a><\/noindex>, kter\u00e9 umo\u017e\u0148uje vypr\u00e1zdnit na disk pouze \u010d\u00e1st souboru, a ne cel\u00fd soubor. Toto vol\u00e1n\u00ed iniciuje asynchronn\u00ed vypr\u00e1zdn\u011bn\u00ed dat a ne\u010dek\u00e1 na jeho dokon\u010den\u00ed. Ale v dokumentaci k sync_file_range()<\/code> se uv\u00e1d\u00ed, \u017ee tento p\u0159\u00edkaz je \"velmi nebezpe\u010dn\u00fd\". Doporu\u010duje se j\u00edm nezab\u00fdvat. Vlastnosti a nebezpe\u010d\u00ed sync_file_range()<\/code> jsou velmi dob\u0159e pops\u00e1ny v tomto<\/a><\/noindex> materi\u00e1lu. Konkr\u00e9tn\u011b se zd\u00e1, \u017ee toto vol\u00e1n\u00ed pou\u017e\u00edv\u00e1 RocksDB k \u0159\u00edzen\u00ed toho, kdy j\u00e1dro vypr\u00e1zdn\u00ed \"\u0161pinav\u00e1\" data na disk. Ale p\u0159itom tam, pro zaji\u0161t\u011bn\u00ed trval\u00e9ho ukl\u00e1d\u00e1n\u00ed dat, je tak\u00e9 pou\u017e\u00edv\u00e1n fdatasync()<\/code>. V k\u00f3d\u011b<\/a><\/noindex> RocksDB jsou zaj\u00edmav\u00e9 koment\u00e1\u0159e na toto t\u00e9ma. Nap\u0159\u00edklad se zd\u00e1, \u017ee vol\u00e1n\u00ed sync_file_range()<\/code> p\u0159i pou\u017eit\u00ed ZFS nevede k vypr\u00e1zdn\u011bn\u00ed dat na disk. Zku\u0161enost mi \u0159\u00edk\u00e1, \u017ee k\u00f3d, kter\u00fd se pou\u017e\u00edv\u00e1 z\u0159\u00eddka, m\u016f\u017ee obsahovat chyby. Proto bych doporu\u010dil nepou\u017e\u00edvat toto syst\u00e9mov\u00e9 vol\u00e1n\u00ed bez krajn\u00ed pot\u0159eby.<\/p>\n

Syst\u00e9mov\u00e1 vol\u00e1n\u00ed, kter\u00e9 pom\u00e1haj\u00ed zajistit trval\u00e9 ukl\u00e1d\u00e1n\u00ed dat<\/h2>\n

\nDosel jsem \u043a z\u00e1v\u011bru, \u017ee pro prov\u00e1d\u011bn\u00ed operac\u00ed vstupu\/v\u00fdstupu, kter\u00e9 zaji\u0161\u0165uj\u00ed spolehliv\u00e9 uchov\u00e1v\u00e1n\u00ed dat, je mo\u017en\u00e9 pou\u017e\u00edvat t\u0159i p\u0159\u00edstupy. V\u0161echny tyto p\u0159\u00edstupy vy\u017eaduj\u00ed vol\u00e1n\u00ed funkce fsync()<\/code> pro adres\u00e1\u0159, ve kter\u00e9m byl soubor vytvo\u0159en. Zde jsou tyto p\u0159\u00edstupy:<\/p>\n

    \n
  1. Vol\u00e1n\u00ed funkce fdatasync()<\/code> nebo fsync()<\/code> po funkci write()<\/code> (lep\u0161\u00ed je pou\u017e\u00edvat fdatasync()<\/code>).<\/li>\n
  2. Pr\u00e1ce s deskriptorem souboru otev\u0159en\u00fdm s p\u0159\u00edznakem O_DSYNC<\/code> nebo O_SYNC<\/code> (lep\u0161\u00ed \u2014 s p\u0159\u00edznakem O_DSYNC<\/code>).<\/li>\n
  3. Pou\u017eit\u00ed p\u0159\u00edkazu pwritev2()<\/code> s p\u0159\u00edznakem RWF_DSYNC<\/code> nebo RWF_SYNC<\/code> (preferovan\u011b \u2014 s p\u0159\u00edznakem RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Pozn\u00e1mky k v\u00fdkonu<\/h2>\n

    \nNev\u011bnoval jsem se pe\u010dliv\u00e9mu m\u011b\u0159en\u00ed v\u00fdkonu r\u016fzn\u00fdch mechanism\u016f, kter\u00e9 jsem prozkoumal. Zjistil jsem, \u017ee rozd\u00edly v rychlosti jejich pr\u00e1ce jsou velmi mal\u00e9. To znamen\u00e1, \u017ee se mohu m\u00fdlit a \u017ee za jin\u00fdch podm\u00ednek m\u016f\u017ee tot\u00e9\u017e vyk\u00e1zat jin\u00e9 v\u00fdsledky. Nejprve se zm\u00edn\u00edm o tom, co m\u00e1 v\u011bt\u0161\u00ed vliv na v\u00fdkon, a pot\u00e9 o tom, co m\u00e1 na v\u00fdkon men\u0161\u00ed vliv.<\/p>\n

      \n
    1. P\u0159episov\u00e1n\u00ed dat v souboru je rychlej\u0161\u00ed ne\u017e p\u0159ipojen\u00ed dat k souboru (zisk v v\u00fdkonu m\u016f\u017ee b\u00fdt 2-100%). P\u0159ipojen\u00ed dat k souboru vy\u017eaduje dal\u0161\u00ed zm\u011bny v metadatech souboru, dokonce i po syst\u00e9mov\u00e9m vol\u00e1n\u00ed fallocate()<\/code>, ale rozsah tohoto efektu se m\u016f\u017ee m\u011bnit. Doporu\u010duji pro zaji\u0161t\u011bn\u00ed nejlep\u0161\u00edho v\u00fdkonu volat fallocate()<\/code> pro p\u0159edb\u011b\u017en\u00e9 p\u0159id\u011blen\u00ed pot\u0159ebn\u00e9ho prostoru. Pot\u00e9 je t\u0159eba toto m\u00edsto v\u00fdslovn\u011b naplnit nulami a zavolat fsync()<\/code>. D\u00edky tomu budou odpov\u00eddaj\u00edc\u00ed bloky v souborov\u00e9m syst\u00e9mu ozna\u010deny jako 'p\u0159id\u011blen\u00e9', a ne jako 'nep\u0159id\u011blen\u00e9'. To p\u0159in\u00e1\u0161\u00ed mal\u00e9 (asi 2%) zlep\u0161en\u00ed v\u00fdkonu. Krom\u011b toho u n\u011bkter\u00fdch disk\u016f m\u016f\u017ee b\u00fdt prvn\u00ed operace p\u0159\u00edstupu k bloku pomalej\u0161\u00ed ne\u017e ostatn\u00ed. To znamen\u00e1, \u017ee vypln\u011bn\u00ed m\u00edsta nulami m\u016f\u017ee v\u00e9st k v\u00fdznamn\u00e9mu (asi 100%) zlep\u0161en\u00ed v\u00fdkonu. To se zejm\u00e9na m\u016f\u017ee st\u00e1t u disk\u016f AWS EBS<\/a><\/noindex> (toto jsou neofici\u00e1ln\u00ed \u00fadaje, kter\u00e9 jsem nemohl potvrdit). Tot\u00e9\u017e plat\u00ed i pro \u00falo\u017ei\u0161t\u011b GCP Persistent Disk<\/a><\/noindex> (a toto je u\u017e ofici\u00e1ln\u00ed informace, kterou potvrdily testy). Jin\u00ed odborn\u00edci u\u010dinili podobn\u00e1 pozorov\u00e1n\u00ed<\/a><\/noindex>, kter\u00e1 se t\u00fdkaj\u00ed r\u016fzn\u00fdch disk\u016f.<\/li>\n
    2. \u010c\u00edm m\u00e9n\u011b syst\u00e9mov\u00fdch vol\u00e1n\u00ed \u2014 t\u00edm vy\u0161\u0161\u00ed v\u00fdkon (zisk m\u016f\u017ee b\u00fdt p\u0159ibli\u017en\u011b 5%). Zd\u00e1 se, \u017ee vol\u00e1n\u00ed open()<\/code> s p\u0159\u00edznakem O_DSYNC<\/code> nebo vol\u00e1n\u00ed pwritev2()<\/code> s p\u0159\u00edznakem RWF_SYNC<\/code> rychleji vol\u00e1n\u00ed fdatasync()<\/code>. Podez\u0159\u00edv\u00e1m, \u017ee to m\u00e1 co do \u010din\u011bn\u00ed s t\u00edm, \u017ee p\u0159i takov\u00e9m p\u0159\u00edstupu hraje roli to, \u017ee pro vy\u0159e\u0161en\u00ed stejn\u00e9ho \u00fakolu je pot\u0159eba prov\u00e9st m\u00e9n\u011b syst\u00e9mov\u00fdch vol\u00e1n\u00ed (jedno vol\u00e1n\u00ed m\u00edsto dvou). Ale rozd\u00edl v v\u00fdkonu je velmi mal\u00fd, tak\u017ee se na n\u011bj m\u016f\u017eete klidn\u011b vyka\u0161lat a v aplikaci pou\u017e\u00edt to, co nezkomplikuje jej\u00ed logiku.<\/li>\n<\/ol>\n

      \nPokud v\u00e1s zaj\u00edm\u00e1 t\u00e9ma trval\u00e9ho ukl\u00e1d\u00e1n\u00ed dat \u2014 zde je n\u011bkolik u\u017eite\u010dn\u00fdch materi\u00e1l\u016f:<\/p>\n