{"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\/hu\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"Fenntarthat\u00f3 adat- \u00e9s f\u00e1jl API-k Linuxban","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mik\u00f6zben az adatok felh\u0151beli t\u00e1rol\u00e1s\u00e1nak megb\u00edzhat\u00f3s\u00e1g\u00e1t kutattam, \u00fagy d\u00f6nt\u00f6ttem, hogy tesztelem magam, \u00e9s megbizonyosodom arr\u00f3l, hogy \u00e9rtem az alapvet\u0151 dolgokat. \u00c9n az NVMe specifik\u00e1ci\u00f3 olvas\u00e1s\u00e1val kezdtem<\/a><\/noindex> hogy meg\u00e9rthessem, milyen garanci\u00e1k vonatkoznak az adatok megb\u00edzhat\u00f3 t\u00e1rol\u00e1s\u00e1ra (vagyis a garanci\u00e1k arra, hogy az adatok el\u00e9rhet\u0151k lesznek a rendszerhib\u00e1k ut\u00e1n), amelyeket az NVMe meghajt\u00f3k biztos\u00edtanak. A k\u00f6vetkez\u0151 f\u0151bb k\u00f6vetkeztet\u00e9seket vontam le: az adatok s\u00e9r\u00fcltnek tekinthet\u0151k att\u00f3l a pillanatt\u00f3l kezdve, amikor a rendszer k\u00f6r\u00fcli parancsot kiadj\u00e1k, eg\u00e9szen addig, am\u00edg a t\u00e1rol\u00f3ra val\u00f3 \u00edr\u00e1s befejez\u0151dik. Azonban a legt\u00f6bb adat\u00edr\u00f3 programban a rendszerh\u00edv\u00e1sok teljesen norm\u00e1lisan haszn\u00e1lhat\u00f3k.<\/p>\n

Ebben az anyagban azokat a megb\u00edzhat\u00f3 t\u00e1rol\u00e1si mechanizmusokat kutatom, amelyeket a Linux f\u00e1jl API-k biztos\u00edtanak. \u00dagy t\u0171nik, hogy itt minden egyszer\u0171 kellene legyen: a program kiad egy parancsot, write()<\/code>, \u00e9s amint a parancs befejez\u0151dik, az adatok megb\u00edzhat\u00f3an t\u00e1rolva lesznek a lemezen. De write()<\/code> csak az alkalmaz\u00e1s adatait m\u00e1solja a mem\u00f3ri\u00e1ban tal\u00e1lhat\u00f3 kernel gyors\u00edt\u00f3t\u00e1r\u00e1ba. Ahhoz, hogy a rendszert arra k\u00e9nyszer\u00edts\u00fck, hogy az adatokat a lemezre \u00edrja, n\u00e9h\u00e1ny tov\u00e1bbi mechanizmust kell haszn\u00e1lni.<\/p>\n

\"Fenntarthat\u00f3<\/a><\/noindex><\/p>\n

\u00d6sszess\u00e9g\u00e9ben ez az anyag egy olyan jegyzetek gy\u0171jtem\u00e9nye, amely a t\u00e9m\u00e1val kapcsolatos tud\u00e1somra \u00e9p\u00fcl. Ha nagyon r\u00f6viden szeretn\u00e9m \u00f6sszefoglalni a legfontosabbat, akkor azt mondhatom, hogy az adatok megb\u00edzhat\u00f3 t\u00e1rol\u00e1s\u00e1nak megszervez\u00e9s\u00e9hez a k\u00f6vetkez\u0151 parancsot kell haszn\u00e1lni: fdatasync()<\/code> vagy f\u00e1jlokat O_DSYNC<\/code>flaggal kell megnyitni. Ha r\u00e9szletesebben szeretne megtudni arr\u00f3l, hogy mi t\u00f6rt\u00e9nik az adatokkal a programk\u00f3db\u00f3l a lemezre val\u00f3 \u00e1tad\u00e1sig, n\u00e9zze meg a erre<\/a><\/noindex> a cikkre.
\n<\/a><\/noindex><\/p>\n

A write() f\u00fcggv\u00e9ny haszn\u00e1lat\u00e1nak saj\u00e1toss\u00e1gai<\/h2>\n

\nA rendszerh\u00edv\u00e1s write()<\/code> a k\u00f6vetkez\u0151 szabv\u00e1nyban van defini\u00e1lva: IEEE POSIX<\/a><\/noindex> mint az adatok pr\u00f3b\u00e1lkoz\u00e1sa a f\u00e1jl le\u00edr\u00f3ba val\u00f3 \u00edr\u00e1s\u00e1ra. A m\u0171velet sikeres befejez\u00e9se ut\u00e1n write()<\/code> az olvas\u00e1si m\u0171veleteknek pontosan azokat a byte-okat kell visszaadniuk, amelyeket kor\u00e1bban \u00edrtak, m\u00e9g akkor is, ha m\u00e1s folyamatok vagy sz\u00e1lak hozz\u00e1f\u00e9rnek az adatokhoz (itt van<\/a><\/noindex> a POSIX szabv\u00e1ny megfelel\u0151 r\u00e9sze). Itt<\/a><\/noindex>, a sz\u00e1lak \u00e9s a hagyom\u00e1nyos f\u00e1jlkezel\u00e9si m\u0171veletek interakci\u00f3j\u00e1ra vonatkoz\u00f3 r\u00e9szben van egy megjegyz\u00e9s, amely hangs\u00falyozza, hogy ha mindk\u00e9t sz\u00e1l ezeket a funkci\u00f3kat h\u00edvja meg, akkor minden egyes h\u00edv\u00e1snak vagy az \u00f6sszes jelzett k\u00f6vetkezm\u00e9nyt kell l\u00e1tnia, amelyet egy m\u00e1sik h\u00edv\u00e1s v\u00e9grehajt\u00e1sa okoz, vagy egy\u00e1ltal\u00e1n semmilyen k\u00f6vetkezm\u00e9nyt. Ez lehet\u0151v\u00e9 teszi arra a k\u00f6vetkeztet\u00e9sre jut\u00e1st, hogy minden bemeneti\/kimeneti f\u00e1jlm\u0171veletnek meg kell tartania a blokkol\u00e1s er\u0151forr\u00e1st, amellyel dolgozik.<\/p>\n

Jelenti ez azt, hogy a m\u0171velet write()<\/code> atomikus? Technikai szempontb\u00f3l \u2014 igen. Az adatolvas\u00e1si m\u0171veleteknek vagy mindent, vagy semmit kell visszaadniuk a write()<\/code>seg\u00edts\u00e9g\u00e9vel \u00edrt adatokb\u00f3l. De a m\u0171velet write()<\/code>, a szabv\u00e1nynak megfelel\u0151en, nem k\u00f6teles \u00fagy befejez\u0151dni, hogy mindent, amit \u00edrtak neki, t\u00e9nylegesen r\u00f6gz\u00edt. Enged\u00e9lyezett sz\u00e1m\u00e1ra, hogy csak egy r\u00e9sz\u00e9t a dat\u00e1nak \u00edrja be. P\u00e9ld\u00e1ul lehet k\u00e9t sz\u00e1lunk, amelyek mindegyike 1024 b\u00e1jtot csatol a f\u00e1jlhoz, amely egy \u00e9s ugyanazon f\u00e1jlle\u00edr\u00f3val van le\u00edrva. A szabv\u00e1ny szempontj\u00e1b\u00f3l a megengedett eredm\u00e9ny az, amikor mindegyik \u00edr\u00e1si m\u0171velet csak egy b\u00e1jtot k\u00e9pes csatolni a f\u00e1jlhoz. Ezek a m\u0171veletek atomikusak maradnak, de miut\u00e1n befejez\u0151dnek, az \u00e1ltaluk a f\u00e1jlba \u00edrt adatok keveredve lesznek. \u00cdme<\/a><\/noindex> nagyon \u00e9rdekes vita folyik e t\u00e9m\u00e1ban a Stack Overflow-on.<\/p>\n

Az fsync() \u00e9s fdatasync() f\u00fcggv\u00e9nyek<\/h2>\n

\nA legk\u00f6nnyebb m\u00f3dja az adatok lemezre \u00edr\u00e1s\u00e1nak funkci\u00f3 h\u00edv\u00e1s\u00e1nak, fsync()<\/a><\/noindex>. Ez a funkci\u00f3 arra k\u00e9ri az oper\u00e1ci\u00f3s rendszert, hogy a m\u00f3dos\u00edtott blokkokat a gyors\u00edt\u00f3t\u00e1rb\u00f3l \u00e1tvigye a lemezre. Ide tartozik az \u00f6sszes f\u00e1jlmetainform\u00e1ci\u00f3 (hozz\u00e1f\u00e9r\u00e9si id\u0151, f\u00e1jl m\u00f3dos\u00edt\u00e1si ideje stb.). \u00dagy v\u00e9lem, hogy ezekre a metainform\u00e1ci\u00f3kra ritk\u00e1n van sz\u00fcks\u00e9g, ez\u00e9rt ha tudod, hogy sz\u00e1modra nem fontosak, haszn\u00e1lhatod a fdatasync()<\/code>. A seg\u00edts\u00e9get<\/a><\/noindex> hogy fdatasync()<\/code> azt mondja, hogy ennek a funkci\u00f3nak a m\u0171k\u00f6d\u00e9se sor\u00e1n a lemezre \u00edr\u00e1sra ker\u00fcl a metainform\u00e1ci\u00f3k olyan mennyis\u00e9ge, amely \"sz\u00fcks\u00e9ges a k\u00f6vetkez\u0151 adatolvas\u00e1si m\u0171veletek megfelel\u0151 v\u00e9grehajt\u00e1s\u00e1hoz\". \u00c9s ez pontosan az, ami a legt\u00f6bb alkalmaz\u00e1st \u00e9rdekli.<\/p>\n

Az egyik probl\u00e9ma, amely itt felmer\u00fclhet, hogy ezek a mechanizmusok nem garant\u00e1lj\u00e1k, hogy a f\u00e1jl felfedezhet\u0151 lesz egy esetleges hiba ut\u00e1n. K\u00fcl\u00f6n\u00f6sen, amikor \u00faj f\u00e1jlt hoznak l\u00e9tre, sz\u00fcks\u00e9ges a fsync()<\/code> a k\u00f6nyvt\u00e1r sz\u00e1m\u00e1ra, amely tartalmazza azt. K\u00fcl\u00f6nben el\u0151fordulhat, hogy a hiba ut\u00e1n ez a f\u00e1jl nem l\u00e9tezik. Ennek oka az, hogy UNIX k\u00f6rnyezetben a kem\u00e9ny linkek alkalmaz\u00e1sa miatt a f\u00e1jl t\u00f6bb k\u00f6nyvt\u00e1rban is l\u00e9tezhet. Ez\u00e9rt a h\u00edv\u00e1skor fsync()<\/code> nincs m\u00f3d a f\u00e1jl sz\u00e1m\u00e1ra, hogy megtudja, hogy melyik k\u00f6nyvt\u00e1r adatait is kell a lemezre \u00edrni (itt<\/a><\/noindex> err\u0151l b\u0151vebben olvashat). \u00dagy t\u0171nik, hogy az ext4 f\u00e1jlrendszer k\u00e9pes automatikusan<\/a><\/noindex> alkalmazni fsync()<\/code> a megfelel\u0151 f\u00e1jlokat tartalmaz\u00f3 k\u00f6nyvt\u00e1rakra, de m\u00e1s f\u00e1jlrendszerek eset\u00e9ben ez nem biztos, hogy \u00edgy van.<\/p>\n

Ez a mechanizmus k\u00fcl\u00f6nb\u00f6z\u0151 m\u00f3dokon val\u00f3sulhat meg a k\u00fcl\u00f6nb\u00f6z\u0151 f\u00e1jlrendszerekben. Haszn\u00e1latba vettem a blktrace-t<\/a><\/noindex> annak meg\u00e9rt\u00e9s\u00e9re, hogy milyen lemezm\u0171veleteket haszn\u00e1lnak az ext4 \u00e9s XFS f\u00e1jlrendszerek. Mindkett\u0151 norm\u00e1l lemez\u00edr\u00e1si parancsokat ad ki a f\u00e1jlok tartalm\u00e1ra \u00e9s a f\u00e1jlrendszer napl\u00f3j\u00e1ra is, ki\u00fcr\u00edti a gyors\u00edt\u00f3t\u00e1rat \u00e9s befejezi a m\u0171k\u00f6d\u00e9st, v\u00e9grehajtva az FUA (Force Unit Access, az adatok k\u00f6zvetlen \u00edr\u00e1sa a lemezre a gyors\u00edt\u00f3t\u00e1r megker\u00fcl\u00e9s\u00e9vel) \u00edr\u00e1st a napl\u00f3ba. Val\u00f3sz\u00edn\u0171leg \u00edgy j\u00e1rnak el annak \u00e9rdek\u00e9ben, hogy meger\u0151s\u00edts\u00e9k a m\u0171velet v\u00e9grehajt\u00e1s\u00e1nak t\u00e9ny\u00e9t. Azokon a lemezeken, amelyek nem t\u00e1mogatj\u00e1k a FUA-t, ez k\u00e9t gyors\u00edt\u00f3t\u00e1raz\u00e1st okoz. K\u00eds\u00e9rleteim azt mutatt\u00e1k, hogy fdatasync()<\/code> kiss\u00e9 gyorsabb fsync()<\/code>. Seg\u00e9dprogram blktrace-t<\/code> arra utal, hogy fdatasync()<\/code> \u00e1ltal\u00e1ban kevesebb adatot \u00edr a lemezre (az ext4-ben fsync()<\/code> 20 KiB-ot \u00edr, m\u00edg fdatasync()<\/code> 16 KiB-ot). Ezenk\u00edv\u00fcl kider\u00edtettem, hogy az XFS egy kicsit gyorsabb, mint az ext4. Ezzel kapcsolatban blktrace-t<\/code> tudtam meg, hogy fdatasync()<\/code> kevesebb adatot \u00edr a lemezre (4 KiB az XFS-ben).<\/p>\n

K\u00e9tes helyzetek, amelyek az fsync() haszn\u00e1lat\u00e1val mer\u00fclnek fel<\/h2>\n

\nh\u00e1rom k\u00e9tes helyzetet tudok felid\u00e9zni, amelyek kapcsol\u00f3dnak fsync()<\/code>, amelyekkel a gyakorlatban tal\u00e1lkoztam.<\/p>\n

Az els\u0151 eset 2008-ban t\u00f6rt\u00e9nt. Akkor a Firefox 3 fel\u00fclete 'beragadt', amikor nagy mennyis\u00e9g\u0171 f\u00e1jl \u00edr\u00e1sa zajlott a lemezre. A probl\u00e9ma az volt, hogy a fel\u00fclet \u00e1llapot\u00e1nak t\u00e1rol\u00e1s\u00e1ra SQLite adatb\u00e1zist haszn\u00e1ltak. Minden egyes v\u00e1ltoz\u00e1s ut\u00e1n, ami a fel\u00fcleten t\u00f6rt\u00e9nt, a fsync()<\/code>f\u00fcggv\u00e9ny h\u00edv\u00e1sa t\u00f6rt\u00e9nt, amely j\u00f3 garanci\u00e1t ny\u00fajtott az adatok tart\u00f3s t\u00e1rol\u00e1s\u00e1ra. Az akkor haszn\u00e1lt ext3 f\u00e1jlrendszerben a f\u00fcggv\u00e9ny fsync()<\/code> minden \"piszkos\" oldalt a rendszeren a lemezre \u00edrt\u00e1k, nem csak azokat, amelyek a megfelel\u0151 f\u00e1jlhoz tartoztak. Ez azt jelentette, hogy a Firefoxban egy gombra kattintva megabytes adat \u00edr\u00f3dhatott a m\u00e1gneses lemezre, ami sok m\u00e1sodpercet vehetett ig\u00e9nybe. A probl\u00e9ma megold\u00e1sa, ahogyan azt meg\u00e9rtettem, ez<\/a><\/noindex> abban rejlett, hogy az adatb\u00e1zis-kezel\u00e9st aszinkron h\u00e1tt\u00e9rfeladatokk\u00e1 kellett \u00e1thelyezni. Ez azt jelenti, hogy a Firefoxban kor\u00e1bban szigor\u00fabb k\u00f6vetelm\u00e9nyek voltak a adatmeg\u0151rz\u00e9s megb\u00edzhat\u00f3s\u00e1g\u00e1val kapcsolatban, mint amennyire val\u00f3j\u00e1ban sz\u00fcks\u00e9g volt, \u00e9s az ext3 f\u00e1jlrendszer jellemz\u0151i csak s\u00falyosb\u00edtott\u00e1k ezt a probl\u00e9m\u00e1t.<\/p>\n

A m\u00e1sodik ellentmond\u00e1s 2009-ben t\u00f6rt\u00e9nt. Akkor, a rendszer le\u00e1ll\u00e1sa ut\u00e1n, az \u00faj ext4 f\u00e1jlrendszer felhaszn\u00e1l\u00f3i szembes\u00fcltek azzal, hogy sok, nemr\u00e9giben l\u00e9trehozott f\u00e1jl hossza nulla, m\u00edg a r\u00e9gi ext3 f\u00e1jlrendszern\u00e9l ilyesmi nem fordult el\u0151. Az el\u0151z\u0151 bekezd\u00e9sben azt mondtam, hogy az ext3 t\u00fal sok adatot \u00edrt a lemezre, ami jelent\u0151sen lelass\u00edtotta a m\u0171k\u00f6d\u00e9st fsync()<\/code>. Ahhoz, hogy javuljon a helyzet, az ext4 csak azokat a \"piszkos\" oldalakat \u00edrja a lemezre, amelyek a konkr\u00e9t f\u00e1jlhoz tartoznak. M\u00e1s f\u00e1jlok adatai sokkal hosszabb ideig maradnak a mem\u00f3ri\u00e1ban, mint az ext3 haszn\u00e1lata eset\u00e9n. Ezt a teljes\u00edtm\u00e9nyjav\u00edt\u00e1s \u00e9rdek\u00e9ben tett\u00e9k (alap\u00e9rtelmez\u00e9s szerint az adatok 30 m\u00e1sodpercig maradnak ilyen \u00e1llapotban, ezt a dirty_expire_centisecs<\/a><\/noindex>; itt<\/a><\/noindex> seg\u00edts\u00e9g\u00e9vel \u00e1ll\u00edthatjuk be). Ez azt jelenti, hogy nagy mennyis\u00e9g\u0171 adat v\u00e9glegesen elveszhet a rendszer le\u00e1ll\u00e1sa ut\u00e1n. A probl\u00e9ma megold\u00e1sa az, hogy fsync()<\/code> alkalmaz\u00e1sokban, amelyeknek biztos\u00edtaniuk kell az adatok megb\u00edzhat\u00f3 t\u00e1rol\u00e1s\u00e1t, \u00e9s maximumra kell cs\u00f6kkenteni\u00fck azok vesz\u00e9lyeit a le\u00e1ll\u00e1sok k\u00f6vetkezm\u00e9nyeivel szemben. A fsync()<\/code> fokozottan hat\u00e9konyabban m\u0171k\u00f6dik ext4 haszn\u00e1lata eset\u00e9n, mint ext3 eset\u00e9n. Ennek a megk\u00f6zel\u00edt\u00e9snek a h\u00e1tr\u00e1nya, hogy a haszn\u00e1lata, mint kor\u00e1bban, lass\u00edt bizonyos m\u0171veletek v\u00e9grehajt\u00e1s\u00e1t, p\u00e9ld\u00e1ul a programok telep\u00edt\u00e9s\u00e9t. A r\u00e9szletek\u00e9rt l\u00e1sd itt<\/a><\/noindex> \u00e9s itt<\/a><\/noindex>.<\/p>\n

A harmadik probl\u00e9ma, amely fsync()<\/code>, 2018-ban mer\u00fclt fel. Akkor a PostgreSQL projekt keret\u00e9ben kider\u00fclt, hogy ha a fsync()<\/code> funkci\u00f3 hib\u00e1ba \u00fctk\u00f6zik, a \"piszkos\" oldalakat \u201etiszta\u201d-k\u00e9nt jel\u00f6li meg. Ennek eredm\u00e9nyek\u00e9nt a k\u00f6vetkez\u0151 h\u00edv\u00e1sok fsync()<\/code> Nem csin\u00e1lnak semmit az ilyen oldalakkal. Ennek k\u00f6vetkezt\u00e9ben a m\u00f3dos\u00edtott oldalak a mem\u00f3ri\u00e1ban maradnak, \u00e9s soha nem ker\u00fclnek \u00edr\u00e1sra a lemezre. Ez val\u00f3di katasztr\u00f3fa, mivel az alkalmaz\u00e1s azt fogja hinni, hogy bizonyos adatok \u00edr\u00f3dtak a lemezre, pedig val\u00f3j\u00e1ban nem. Az ilyen hib\u00e1k fsync()<\/code> ritk\u00e1n fordulnak el\u0151, ilyenkor az alkalmaz\u00e1s szinte semmit nem tud tenni a probl\u00e9ma kezel\u00e9s\u00e9\u00e9rt. Manaps\u00e1g, amikor ez megt\u00f6rt\u00e9nik, a PostgreSQL \u00e9s m\u00e1s alkalmaz\u00e1sok v\u00e1ratlanul le\u00e1llnak. Itt<\/a><\/noindex>, a \"Can Applications Recover from fsync Failures?\" c\u00edm\u0171 anyagban ezt a probl\u00e9m\u00e1t r\u00e9szletesen vizsg\u00e1lj\u00e1k. Jelenleg a legjobb megold\u00e1s erre a probl\u00e9m\u00e1ra a Direct I\/O haszn\u00e1lata az O_SYNC<\/code> vagy az O_DSYNC<\/code>flaggel. Ezen megk\u00f6zel\u00edt\u00e9ssel a rendszer jelenteni fogja az adat\u00edr\u00e1si m\u0171veletek sor\u00e1n fell\u00e9p\u0151 hib\u00e1kat, azonban ez a megold\u00e1s azt ig\u00e9nyli, hogy az alkalmaz\u00e1s \u00f6n\u00e1ll\u00f3an kezelje a pufferel\u00e9st. A r\u00e9szletek\u00e9rt olvasson el itt<\/a><\/noindex> \u00e9s itt<\/a><\/noindex>.<\/p>\n

F\u00e1jlok megnyit\u00e1sa O_SYNC \u00e9s O_DSYNC z\u00e1szl\u00f3kkal<\/h2>\n

\nT\u00e9rj\u00fcnk vissza a Linux-mechanizmusok megvitat\u00e1s\u00e1hoz, amelyek biztos\u00edtj\u00e1k az adatok megb\u00edzhat\u00f3 t\u00e1rol\u00e1s\u00e1t. Pontosabban, a O_SYNC<\/code> vagy a O_DSYNC<\/code> haszn\u00e1lat\u00e1r\u00f3l van sz\u00f3 f\u00e1jlok megnyit\u00e1sakor a rendszerh\u00edv\u00e1s sor\u00e1n. open()<\/a><\/noindex>. Ezen megk\u00f6zel\u00edt\u00e9ssel minden adat\u00edr\u00e1si m\u0171velet \u00fagy val\u00f3sul meg, mintha minden parancs ut\u00e1n write()<\/code> a rendszer megkapn\u00e1 a megfelel\u0151 parancsokat fsync()<\/code> \u00e9s fdatasync()<\/code>. A a POSIX specifik\u00e1ci\u00f3 szerint<\/a><\/noindex> ezt \"Synchronized I\/O File Integrity Completion\" \u00e9s \"Data Integrity Completion\" n\u00e9ven ismerik. Ennek a megk\u00f6zel\u00edt\u00e9snek a legnagyobb el\u0151nye, hogy az adatok integrit\u00e1s\u00e1nak biztos\u00edt\u00e1s\u00e1hoz csup\u00e1n egy rendszerh\u00edv\u00e1st kell v\u00e9grehajtani, nem kett\u0151t (p\u00e9ld\u00e1ul - write()<\/code> \u00e9s fdatasync()<\/code>). E megk\u00f6zel\u00edt\u00e9s legf\u0151bb h\u00e1tr\u00e1nya, hogy minden \u00edr\u00e1si m\u0171velet, amely a megfelel\u0151 f\u00e1jlle\u00edr\u00f3val haszn\u00e1latos, szinkroniz\u00e1lva lesz, ami korl\u00e1tozhatja az alkalmaz\u00e1s k\u00f3dj\u00e1nak strukt\u00far\u00e1z\u00e1s\u00e1ra vonatkoz\u00f3 lehet\u0151s\u00e9geket.<\/p>\n

A Direct I\/O O_DIRECT z\u00e1szl\u00f3val val\u00f3 haszn\u00e1lata<\/h2>\n

\nA rendszerh\u00edv\u00e1s open()<\/code> t\u00e1mogatja a O_DIRECT<\/code>, amelyet arra terveztek, hogy megker\u00fclve az oper\u00e1ci\u00f3s rendszer gyors\u00edt\u00f3t\u00e1r\u00e1t, k\u00f6zvetlen\u00fcl a lemezzel kommunik\u00e1lva hajtsa v\u00e9gre a be- \u00e9s kimeneti m\u0171veleteket. Ez gyakran azt jelenti, hogy a program \u00e1ltal kibocs\u00e1tott \u00edr\u00e1si parancsok k\u00f6zvetlen\u00fcl ker\u00fclnek \u00e1tkonvert\u00e1l\u00e1sra a lemez m\u0171veleteire vonatkoz\u00f3 parancsokk\u00e1. Az \u00e1ltal\u00e1nos esetben azonban ez a mechanizmus nem helyettes\u00edti a fsync()<\/code> vagy fdatasync()<\/code>. A probl\u00e9ma az, hogy mag\u00e1 a lemez k\u00e9sleltetheti vagy gyors\u00edthatja a m\u0171veleteket.<\/a><\/noindex> megfelel\u0151 adatr\u00f6gz\u00edt\u00e9si parancsok. \u00c9s ami m\u00e9g rosszabb, hogy bizonyos speci\u00e1lis esetekben, a bemeneti\/kimeneti m\u0171veletek, amelyek a flag haszn\u00e1lat\u00e1val t\u00f6rt\u00e9nnek, O_DIRECT<\/code>, \u00e1tviteli<\/a><\/noindex> hagyom\u00e1nyos puffert\u00f6lt\u00e9si m\u0171veletekbe. E probl\u00e9ma legk\u00f6nnyebben azzal oldhat\u00f3 meg, ha f\u00e1jlok megnyit\u00e1s\u00e1hoz tov\u00e1bbi flaget is haszn\u00e1lunk, O_DSYNC<\/code>, ami azt jelenti, hogy minden r\u00f6gz\u00edt\u00e9si m\u0171velet ut\u00e1n egy h\u00edv\u00e1s k\u00f6vetkezik. fdatasync()<\/code>.<\/p>\n

Kider\u00fclt, hogy az XFS f\u00e1jlrendszerhez nemr\u00e9giben egy \"gyors \u00fat\" ker\u00fclt hozz\u00e1ad\u00e1sra, O_DIRECT|O_DSYNC<\/code>-adatok r\u00f6gz\u00edt\u00e9s\u00e9hez. Ha egy blokkot fel\u00fcl\u00edrnak a O_DIRECT|O_DSYNC<\/code>, akkor az XFS a cache t\u00f6rl\u00e9se helyett FUA-r\u00f6gz\u00edt\u00e9si parancsot hajt v\u00e9gre, amennyiben az eszk\u00f6z ezt t\u00e1mogatja. Ezt a Linux 5.4 \/ Ubuntu 20.04 rendszer alatt az blktrace-t<\/code> seg\u00edts\u00e9g\u00e9vel tapasztaltam. Ez a megk\u00f6zel\u00edt\u00e9s hat\u00e9konyabbnak kell lennie, mivel a minim\u00e1lis adatmennyis\u00e9get \u00edrja a lemezre, \u00e9s egyetlen m\u0171veletet v\u00e9gez, nem pedig kett\u0151t (r\u00f6gz\u00edt\u00e9st \u00e9s a cache t\u00f6rl\u00e9s\u00e9t). Tal\u00e1ltam egy hivatkoz\u00e1st egy k\u00f3dra ford\u00edt.<\/a><\/noindex> 2018-as kernelre, amelyben ezt a mechanizmust implement\u00e1lt\u00e1k. Ott van egy besz\u00e9lget\u00e9s a m\u00e1s f\u00e1jlrendszerekben t\u00f6rt\u00e9n\u0151 alkalmaz\u00e1s\u00e1r\u00f3l, de amennyire tudom, az XFS egyel\u0151re az egyetlen f\u00e1jlrendszer, amely ezt t\u00e1mogatja.<\/p>\n

sync_file_range() funkci\u00f3<\/h2>\n

\nA Linuxban van egy rendszerh\u00edv\u00e1s sync_file_range()<\/a><\/noindex>, amely lehet\u0151v\u00e9 teszi, hogy csak a f\u00e1jl egy r\u00e9sz\u00e9t \u00edrja a lemezre, nem pedig az eg\u00e9sz f\u00e1jlt. Ez a h\u00edv\u00e1s aszinkron adathal\u00e1sz\u00e1st ind\u00edt el, \u00e9s nem v\u00e1rja meg a befejez\u00e9s\u00e9t. De a sync_file_range()<\/code> seg\u00edts\u00e9g\u00e9vel azt mondj\u00e1k, hogy ezen parancs \"nagyon vesz\u00e9lyes\". nem aj\u00e1nlott\u00e1sra. A r\u00e9szletek \u00e9s vesz\u00e9lyek sync_file_range()<\/code> nagyon j\u00f3l le vannak \u00edrva a mell\u00e9kelt<\/a><\/noindex> anyagon. K\u00fcl\u00f6n\u00f6sen \u00fagy t\u0171nik, hogy ez a h\u00edv\u00e1s a RocksDB-t haszn\u00e1lja az adatok \"piszkos\" lemezre t\u00f6rt\u00e9n\u0151 t\u00f6rl\u00e9s\u00e9nek ir\u00e1ny\u00edt\u00e1s\u00e1ra. De a megb\u00edzhat\u00f3 t\u00e1rol\u00e1s biztos\u00edt\u00e1sa \u00e9rdek\u00e9ben itt is, fdatasync()<\/code>. A k\u00f3d<\/a><\/noindex> A RocksDB-vel kapcsolatban vannak \u00e9rdekes megjegyz\u00e9sek err\u0151l a t\u00e9m\u00e1r\u00f3l. P\u00e9ld\u00e1ul \u00fagy t\u0171nik, hogy a h\u00edv\u00e1s sync_file_range()<\/code> ZFS haszn\u00e1lata eset\u00e9n nem vezet adatfehaszn\u00e1l\u00e1shoz a lemezen. A tapasztalat azt mondja, hogy a ritk\u00e1n haszn\u00e1lt k\u00f3d val\u00f3sz\u00edn\u0171leg hib\u00e1kat tartalmaz. Ez\u00e9rt azt tan\u00e1csoln\u00e1m, hogy ne haszn\u00e1lja ezt a rendszerh\u00edv\u00e1st kiv\u00e9teles sz\u00fcks\u00e9gletek n\u00e9lk\u00fcl.<\/p>\n

A rendszerh\u00edv\u00e1sok, amelyek seg\u00edtenek a megb\u00edzhat\u00f3 adatmeg\u0151rz\u00e9s biztos\u00edt\u00e1s\u00e1ban<\/h2>\n

\nArra jutottam, hogy az adatok megb\u00edzhat\u00f3 t\u00e1rol\u00e1s\u00e1t biztos\u00edt\u00f3 bevitel\/kivitel m\u0171veletek v\u00e9grehajt\u00e1s\u00e1ra h\u00e1rom m\u00f3dszert lehet alkalmazni. Mindegyikhez sz\u00fcks\u00e9ges a f\u00e1jl l\u00e9trehoz\u00e1s\u00e1nak k\u00f6nyvt\u00e1r\u00e1ra vonatkoz\u00f3 f\u00fcggv\u00e9ny megh\u00edv\u00e1sa. fsync()<\/code> Ezek a megk\u00f6zel\u00edt\u00e9sek:<\/p>\n

    \n
  1. Funkci\u00f3h\u00edv\u00e1s fdatasync()<\/code> vagy fsync()<\/code> a f\u00fcggv\u00e9ny ut\u00e1n write()<\/code> (jobb haszn\u00e1lni fdatasync()<\/code>).<\/li>\n
  2. A f\u00e1jlle\u00edr\u00f3val val\u00f3 munka, amelyet a O_DSYNC<\/code> vagy O_SYNC<\/code> (jobb \u2014 a O_DSYNC<\/code>).<\/li>\n
  3. parancs haszn\u00e1lata pwritev2()<\/code> z\u00e1szl\u00f3val RWF_DSYNC<\/code> vagy RWF_SYNC<\/code> (el\u0151ny\u00f6sebb \u2014 a RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Teljes\u00edtm\u00e9ny megjegyz\u00e9sek<\/h2>\n

    \nNem v\u00e9geztem alapos teljes\u00edtm\u00e9nym\u00e9r\u00e9seket a k\u00fcl\u00f6nb\u00f6z\u0151 \u00e1ltalam megvizsg\u00e1lt mechanizmusokr\u00f3l. Az \u00e1ltalam \u00e9szlelt sebess\u00e9gbeli elt\u00e9r\u00e9sek meglehet\u0151sen kicsiek. Ez azt jelenti, hogy t\u00e9vedhetek, \u00e9s hogy m\u00e1s k\u00f6r\u00fclm\u00e9nyek k\u00f6z\u00f6tt ugyanaz m\u00e1s eredm\u00e9nyeket hozhat. El\u0151sz\u00f6r arr\u00f3l fogok besz\u00e9lni, hogy mi befoly\u00e1solja legjobban a teljes\u00edtm\u00e9nyt, majd arr\u00f3l, hogy mi befoly\u00e1solja kev\u00e9sb\u00e9.<\/p>\n

      \n
    1. A f\u00e1jl adatainak fel\u00fcl\u00edr\u00e1sa gyorsabb, mint az adatok f\u00e1jlhoz val\u00f3 hozz\u00e1f\u0171z\u00e9se (a teljes\u00edtm\u00e9ny nyeres\u00e9ge 2-100% k\u00f6z\u00f6tt mozoghat). Az adatok f\u00e1jlhoz val\u00f3 hozz\u00e1f\u0171z\u00e9se tov\u00e1bbi m\u00f3dos\u00edt\u00e1sokat ig\u00e9nyel a f\u00e1jl metaadataiban, m\u00e9g a rendszerh\u00edv\u00e1s ut\u00e1n is. fallocate()<\/code>, de ennek a hat\u00e1snak a m\u00e9rt\u00e9ke v\u00e1ltozhat. A legjobb teljes\u00edtm\u00e9ny biztos\u00edt\u00e1sa \u00e9rdek\u00e9ben javaslom, hogy h\u00edvd meg fallocate()<\/code> a sz\u00fcks\u00e9ges hely el\u0151zetes lefoglal\u00e1s\u00e1ra. Ezt a helyet kifejezetten null\u00e1kkal kell felt\u00f6lteni, majd megh\u00edvni fsync()<\/code>. Ezzel a megfelel\u0151 blokkok a f\u00e1jlrendszerben 'lefoglalt' st\u00e1tuszt kapnak, \u00e9s nem 'nem lefoglalt' st\u00e1tuszt. Ez egy kis (~2%) teljes\u00edtm\u00e9nyn\u00f6veked\u00e9st eredm\u00e9nyez. Ezen k\u00edv\u00fcl egyes t\u00e1rol\u00f3k eset\u00e9ben az els\u0151 blokkhoz val\u00f3 hozz\u00e1f\u00e9r\u00e9s lassabb lehet, mint m\u00e1sok\u00e9. Ez azt jelenti, hogy a hely null\u00e1kkal val\u00f3 felt\u00f6lt\u00e9se jelent\u0151s (~100%) teljes\u00edtm\u00e9nyn\u00f6veked\u00e9st okozhat. K\u00fcl\u00f6n\u00f6sen ez el\u0151fordulhat az AWS EBS<\/a><\/noindex> (ez nem hivatalos adat, amit nem tudtam meger\u0151s\u00edteni). Ugyanez vonatkozik a GCP Persistent Disk<\/a><\/noindex> (ez m\u00e1r hivatalos inform\u00e1ci\u00f3, amelyet tesztel\u00e9sek igazoltak). M\u00e1s szak\u00e9rt\u0151k hasonl\u00f3 megfigyel\u00e9seket tettek,<\/a><\/noindex>, amelyek k\u00fcl\u00f6nb\u00f6z\u0151 t\u00e1rol\u00f3kra vonatkoznak.<\/li>\n
    2. Min\u00e9l kevesebb a rendszerh\u00edv\u00e1s, ann\u00e1l magasabb a teljes\u00edtm\u00e9ny (a nyeres\u00e9g k\u00f6r\u00fclbel\u00fcl 5% lehet). \u00dagy t\u0171nik, hogy a open()<\/code> z\u00e1szl\u00f3val O_DSYNC<\/code> vagy a pwritev2()<\/code> z\u00e1szl\u00f3val RWF_SYNC<\/code> h\u00edv\u00e1s gyorsabb, mint a h\u00edv\u00e1s. fdatasync()<\/code>Gyan\u00edtom, hogy a dolog ott rejlik, hogy e megk\u00f6zel\u00edt\u00e9s eset\u00e9n a szerepet az j\u00e1tssza, hogy ugyanannak a feladatnak a megold\u00e1s\u00e1hoz kevesebb rendszerh\u00edv\u00e1st kell v\u00e9grehajtani (egy h\u00edv\u00e1s a kett\u0151 helyett). De a teljes\u00edtm\u00e9nyk\u00fcl\u00f6nbs\u00e9g nagyon kicsi, ez\u00e9rt nyugodtan figyelmen k\u00edv\u00fcl hagyhatja, \u00e9s haszn\u00e1lhatja az alkalmaz\u00e1sban azt, ami nem bonyol\u00edtja a logik\u00e1j\u00e1t.<\/li>\n<\/ol>\n

      \nHa \u00e9rdekli az adatv\u00e9delem \u00e9s a fenntarthat\u00f3 t\u00e1rol\u00e1s t\u00e9m\u00e1ja, itt van n\u00e9h\u00e1ny hasznos anyag:<\/p>\n