{"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\/pl\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"Trwa\u0142e przechowywanie danych i interfejsy API plik\u00f3w w systemie Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Badaj\u0105c niezawodno\u015b\u0107 przechowywania danych w systemach chmurowych, postanowi\u0142em sprawdzi\u0107 swoje umiej\u0119tno\u015bci i upewni\u0107 si\u0119, \u017ce rozumiem podstawowe zagadnienia. Ja zacz\u0105\u0142em od przeczytania specyfikacji NVMe<\/a><\/noindex> aby zrozumie\u0107, jakie gwarancje dotycz\u0105ce niezawodnego przechowywania danych (to znaczy \u2014 gwarancje, \u017ce dane b\u0119d\u0105 dost\u0119pne po awarii systemu) oferuj\u0105 nam dyski NVMe. Oto moje g\u0142\u00f3wne wnioski: nale\u017cy uzna\u0107 dane za uszkodzone w momencie, gdy zostanie wydane polecenie zapisania danych, a\u017c do momentu, gdy zako\u0144czony zostanie zapis na no\u015bniku informacji. Jednak w wi\u0119kszo\u015bci program\u00f3w do zapisu danych bez obaw u\u017cywa si\u0119 wywo\u0142a\u0144 systemowych.<\/p>\n

W tym artykule badam mechanizmy niezawodnego przechowywania danych oferowane przez API plik\u00f3w w systemie Linux. Wydaje si\u0119, \u017ce wszystko powinno by\u0107 proste: program wywo\u0142uje polecenie write()<\/code>, a po zako\u0144czeniu dzia\u0142ania tej komendy, dane powinny by\u0107 niezawodnie zapisane na dysku. Ale write()<\/code> jedynie kopiuje dane aplikacji do cache'u j\u0105dra znajduj\u0105cego si\u0119 w pami\u0119ci operacyjnej. Aby wymusi\u0107 na systemie zapis danych na dysku, nale\u017cy u\u017cy\u0107 dodatkowych mechanizm\u00f3w.<\/p>\n

\"Trwa\u0142e<\/a><\/noindex><\/p>\n

Og\u00f3lnie rzecz bior\u0105c, ten materia\u0142 stanowi zbi\u00f3r notatek na temat tego, co dowiedzia\u0142em si\u0119 w interesuj\u0105cej mnie dziedzinie. Je\u015bli bardzo skr\u00f3towo opisa\u0107 najwa\u017cniejsze informacje, to okazuje si\u0119, \u017ce do organizacji niezawodnego przechowywania danych nale\u017cy u\u017cywa\u0107 komendy fdatasync()<\/code> lub otwiera\u0107 pliki z flag\u0105 O_DSYNC<\/code>. Je\u015bli chcesz szczeg\u00f3\u0142owo dowiedzie\u0107 si\u0119, co si\u0119 dzieje z danymi w trakcie ich drogi od kodu programu do dysku, zerknij na tego<\/a><\/noindex> artyku\u0142.
\n<\/a><\/noindex><\/p>\n

Cechy u\u017cycia funkcji write()<\/h2>\n

\nWywo\u0142anie systemowe write()<\/code> jest zdefiniowane w standardzie IEEE POSIX<\/a><\/noindex> jako pr\u00f3ba zapisu danych do deskryptora pliku. Po pomy\u015blnym zako\u0144czeniu operacji write()<\/code> operacje odczytu danych powinny zwraca\u0107 dok\u0142adnie te bajty, kt\u00f3re wcze\u015bniej zosta\u0142y zapisane, nawet w przypadku, gdy do danych uzyskuj\u0105 dost\u0119p inne procesy lub w\u0105tki (oto<\/a><\/noindex> odpowiedni rozdzia\u0142 standardu POSIX). Tutaj<\/a><\/noindex>, w sekcji po\u015bwi\u0119conej interakcji strumieni z typowymi operacjami plikowymi, znajduje si\u0119 uwaga, kt\u00f3ra wskazuje, \u017ce je\u015bli ka\u017cdy z dw\u00f3ch strumieni wywo\u0142uje te funkcje, to ka\u017cde wywo\u0142anie powinno widzie\u0107 albo wszystkie okre\u015blone konsekwencje wynikaj\u0105ce z wykonania innego wywo\u0142ania, albo w og\u00f3le \u017cadnych konsekwencji. To pozwala wyci\u0105gn\u0105\u0107 wniosek, \u017ce wszystkie operacje plikowe wej\u015bcia\/wyj\u015bcia musz\u0105 utrzymywa\u0107 blokad\u0119 zasobu, z kt\u00f3rym pracuj\u0105.<\/p>\n

Czy oznacza to, \u017ce operacja write()<\/code> jest atomowa? Technicznie \u2014 tak. Operacje odczytu danych powinny zwraca\u0107 albo wszystko, albo nic z tego, co zosta\u0142o zapisane za pomoc\u0105 write()<\/code>. Jednak operacja write()<\/code>, zgodnie ze standardem, nie musi koniecznie ko\u0144czy\u0107 si\u0119 zapisaniem wszystkiego, co zosta\u0142a poproszona o zapisanie. Mo\u017ce wykona\u0107 zapis tylko cz\u0119\u015bci danych. Na przyk\u0142ad, mamy dwa strumienie, z kt\u00f3rych ka\u017cdy do\u0142\u0105cza 1024 bajty do pliku opisanego tym samym deskryptorem pliku. Z punktu widzenia standardu akceptowalnym wynikiem b\u0119dzie sytuacja, w kt\u00f3rej ka\u017cda z operacji zapisu mo\u017ce do\u0142\u0105czy\u0107 do pliku tylko po jednym bajcie. Operacje te pozostan\u0105 atomowe, ale po ich zako\u0144czeniu dane zapisane przez nie w pliku b\u0119d\u0105 pomieszane. Oto<\/a><\/noindex> bardzo interesuj\u0105ca dyskusja na ten temat na Stack Overflow.<\/p>\n

Funkcje fsync() i fdatasync()<\/h2>\n

\nNajprostszym sposobem na zrzut danych na dysk jest wywo\u0142anie funkcji fsync()<\/a><\/noindex>. Ta funkcja \u017c\u0105da od systemu operacyjnego przeniesienia wszystkich zmodyfikowanych blok\u00f3w z cache na dysk. Obejmuje to tak\u017ce wszystkie metadane pliku (czas dost\u0119pu, czas modyfikacji pliku itd.). Uwa\u017cam, \u017ce potrzeba tych metadanych wyst\u0119puje rzadko, wi\u0119c je\u015bli wiesz, \u017ce nie s\u0105 dla ciebie istotne, mo\u017cesz korzysta\u0107 z funkcji fdatasync()<\/code>. W pomocy<\/a><\/noindex> w fdatasync()<\/code> , m\u00f3wi si\u0119, \u017ce w trakcie pracy tej funkcji zapisywany jest na dysk taki wolumen metadanych, kt\u00f3ry \u201ejest niezb\u0119dny do poprawnego wykonania nast\u0119pnych operacji odczytu danych\u201d. A to jest dok\u0142adnie to, co interesuje wi\u0119kszo\u015b\u0107 aplikacji.<\/p>\n

Jednym z problem\u00f3w, kt\u00f3ry mo\u017ce si\u0119 pojawi\u0107, jest to, \u017ce te mechanizmy nie gwarantuj\u0105, \u017ce plik b\u0119dzie mo\u017cliwy do odnalezienia po ewentualnej awarii. W szczeg\u00f3lno\u015bci, gdy tworzy si\u0119 nowy plik, nale\u017cy wywo\u0142a\u0107 fsync()<\/code> dla katalogu, kt\u00f3ry go zawiera. W przeciwnym razie po awarii mo\u017ce okaza\u0107 si\u0119, \u017ce ten plik nie istnieje. Pow\u00f3d tego tkwi w tym, \u017ce w UNIX-ie, z powodu stosowania twardych dowi\u0105za\u0144, plik mo\u017ce istnie\u0107 w kilku katalogach. Dlatego przy wywo\u0142aniu fsync()<\/code> dla pliku nie ma sposobu, aby dowiedzie\u0107 si\u0119, jakie dok\u0142adnie dane z tego katalogu r\u00f3wnie\u017c nale\u017cy zrzuci\u0107 na dysk (tutaj<\/a><\/noindex> mo\u017cna o tym poczyta\u0107 wi\u0119cej). Wydaje si\u0119, \u017ce system plik\u00f3w ext4 jest w stanie automatycznie<\/a><\/noindex> stosowa\u0107 fsync()<\/code> do katalog\u00f3w, kt\u00f3re zawieraj\u0105 odpowiednie pliki, ale w przypadku innych system\u00f3w plik\u00f3w mo\u017ce by\u0107 inaczej.<\/p>\n

Ten mechanizm mo\u017ce by\u0107 r\u00f3\u017cnie wdra\u017cany w r\u00f3\u017cnych systemach plik\u00f3w. U\u017cy\u0142em blktrace<\/a><\/noindex> aby dowiedzie\u0107 si\u0119, jakie operacje dyskowe s\u0105 stosowane w systemach plik\u00f3w ext4 i XFS. Oba systemy wydaj\u0105 standardowe polecenia zapisu na dysk zar\u00f3wno dla zawarto\u015bci plik\u00f3w, jak i dla dziennika systemu plik\u00f3w, zrzucaj\u0105 pami\u0119\u0107 podr\u0119czn\u0105 i ko\u0144cz\u0105 dzia\u0142anie, wykonuj\u0105c zapis FUA (Force Unit Access, zapis danych bezpo\u015brednio na dysk, pomijaj\u0105c pami\u0119\u0107 podr\u0119czn\u0105) w dzienniku. Prawdopodobnie robi\u0105 to, aby potwierdzi\u0107 wykonanie operacji. Na dyskach, kt\u00f3re nie wspieraj\u0105 FUA, powoduje to dwa zrzuty pami\u0119ci podr\u0119cznej. Moje eksperymenty wykaza\u0142y, \u017ce fdatasync()<\/code> nieco szybciej fsync()<\/code>. Narz\u0119dzie blktrace<\/code> wskazuje, \u017ce fdatasync()<\/code> zwykle zapisuje na dysk mniej danych (w ext4 fsync()<\/code> zapisuje 20 KiB, a fdatasync()<\/code> \u2014 16 KiB). Ponadto ustali\u0142em, \u017ce XFS jest nieco szybszy ni\u017c ext4. A tu z pomoc\u0105 blktrace<\/code> uda\u0142o si\u0119 dowiedzie\u0107, \u017ce fdatasync()<\/code> zrzuca na dysk mniej danych (4 KiB w XFS).<\/p>\n

Niejednoznaczne sytuacje zwi\u0105zane z u\u017cywaniem fsync()<\/h2>\n

\nMog\u0119 przypomnie\u0107 sobie trzy niejednoznaczne sytuacje dotycz\u0105ce fsync()<\/code>, z kt\u00f3rymi spotka\u0142em si\u0119 w praktyce.<\/p>\n

Pierwszy taki przypadek zdarzy\u0142 si\u0119 w 2008 roku. Wtedy interfejs Firefox 3 'zawiesza\u0142 si\u0119', gdy wykonywano zapis na dysk du\u017cej liczby plik\u00f3w. Problem polega\u0142 na tym, \u017ce w implementacji interfejsu do przechowywania informacji o jego stanie u\u017cywano bazy danych SQLite. Po ka\u017cdej zmianie, kt\u00f3ra mia\u0142a miejsce w interfejsie, wywo\u0142ywana by\u0142a funkcja fsync()<\/code>, co dawa\u0142o dobre gwarancje trwa\u0142ego przechowywania danych. W u\u017cywanym w\u00f3wczas systemie plik\u00f3w ext3 funkcja fsync()<\/code> zrzuca\u0142a na dysk wszystkie \"brudne\" strony w systemie, a nie tylko te, kt\u00f3re mia\u0142y zwi\u0105zek z danym plikiem. Oznacza\u0142o to, \u017ce klikni\u0119cie przycisku w Firefoxie mog\u0142o wywo\u0142a\u0107 zapis megabajt\u00f3w danych na dysk magnetyczny, co mog\u0142o zaj\u0105\u0107 wiele sekund. Rozwi\u0105zanie problemu, jak zrozumia\u0142em z tego<\/a><\/noindex> materia\u0142u, polega\u0142o na przeniesieniu pracy z baz\u0105 danych do asynchronicznych zada\u0144 w tle. Oznacza to, \u017ce wcze\u015bniej w Firefoxie wprowadzono bardziej rygorystyczne wymagania dotycz\u0105ce trwa\u0142o\u015bci przechowywania danych, ni\u017c by\u0142o to rzeczywi\u015bcie potrzebne, a cechy systemu plik\u00f3w ext3 tylko pog\u0142\u0119bi\u0142y ten problem.<\/p>\n

Drugie rozbie\u017cno\u015b\u0107 mia\u0142a miejsce w 2009 roku. Po awarii systemu u\u017cytkownicy nowego systemu plik\u00f3w ext4 napotkali problem, \u017ce wiele niedawno utworzonych plik\u00f3w ma zerow\u0105 d\u0142ugo\u015b\u0107, podczas gdy w przypadku starszego systemu plik\u00f3w ext3 co\u015b takiego nie mia\u0142o miejsca. W poprzednim akapicie m\u00f3wi\u0142em o tym, \u017ce ext3 zrzuca\u0142a na dysk zbyt wiele danych, co znacznie spowalnia\u0142o dzia\u0142anie fsync()<\/code>. Aby poprawi\u0107 sytuacj\u0119, w ext4 na dysk zrzucane s\u0105 tylko te \"brudne\" strony, kt\u00f3re maj\u0105 zwi\u0105zek z konkretnym plikiem. A dane innych plik\u00f3w pozostaj\u0105 w pami\u0119ci przez znacznie d\u0142u\u017cszy czas ni\u017c w przypadku stosowania ext3. Zrobiono to w celu poprawy wydajno\u015bci (domy\u015blnie dane pozostaj\u0105 w tym stanie przez 30 sekund, mo\u017cna to dostosowa\u0107 za pomoc\u0105 dirty_expire_centisecs<\/a><\/noindex>; tutaj<\/a><\/noindex> , mo\u017cna znale\u017a\u0107 dodatkowe materia\u0142y na ten temat). Oznacza to, \u017ce du\u017ca ilo\u015b\u0107 danych mo\u017ce zosta\u0107 bezpowrotnie utracona po awarii. Rozwi\u0105zaniem tego problemu jest stosowanie fsync()<\/code> w aplikacjach, kt\u00f3re musz\u0105 zapewni\u0107 trwa\u0142e przechowywanie danych i maksymalnie zabezpieczy\u0107 je przed skutkami awarii. Funkcja fsync()<\/code> dzia\u0142a przy wykorzystaniu ext4 znacznie efektywniej ni\u017c przy u\u017cyciu ext3. Wada tego podej\u015bcia polega na tym, \u017ce jego zastosowanie, jak dawniej, spowalnia wykonanie niekt\u00f3rych operacji, takich jak instalacja program\u00f3w. Szczeg\u00f3\u0142y na ten temat znajdziesz tutaj<\/a><\/noindex> i tutaj<\/a><\/noindex>.<\/p>\n

Trzecia problem, dotycz\u0105cy fsync()<\/code>, pojawi\u0142 si\u0119 w 2018 roku. W\u00f3wczas w ramach projektu PostgreSQL ustalono, \u017ce je\u015bli funkcja fsync()<\/code> napotyka b\u0142\u0105d, oznacza \"brudne\" strony jako \"czyste\". W rezultacie kolejne wywo\u0142ania fsync()<\/code> nic nie robi si\u0119 z takimi stronami. Z tego powodu zmodyfikowane strony s\u0105 przechowywane w pami\u0119ci i nigdy nie s\u0105 zapisywane na dysku. To jest prawdziwa katastrofa, poniewa\u017c aplikacja uzna, \u017ce jakie\u015b dane zosta\u0142y zapisane na dysku, podczas gdy w rzeczywisto\u015bci tak nie jest. Takie awarie fsync()<\/code> zdarzaj\u0105 si\u0119 rzadko, aplikacja w takich sytuacjach prawie nic nie mo\u017ce zrobi\u0107, aby stawi\u0107 czo\u0142a problemowi. W dzisiejszych czasach, gdy to si\u0119 zdarza, PostgreSQL i inne aplikacje ko\u0144cz\u0105 dzia\u0142anie awaryjnie. Tutaj<\/a><\/noindex>, w materiale \u201eCzy aplikacje mog\u0105 odzyska\u0107 si\u0119 z b\u0142\u0119d\u00f3w fsync?\u201d, problem ten jest badany w pe\u0142nych szczeg\u00f3\u0142ach. Obecnie najlepszym rozwi\u0105zaniem tego problemu jest u\u017cycie Direct I\/O z flag\u0105 O_SYNC<\/code> lub z flag\u0105 O_DSYNC<\/code>. Przy takim podej\u015bciu system zg\u0142osi b\u0142\u0119dy, kt\u00f3re mog\u0105 wyst\u0105pi\u0107 podczas wykonywania konkretnych operacji zapisu danych, ale to podej\u015bcie wymaga, aby aplikacja zarz\u0105dza\u0142a buforami samodzielnie. Szczeg\u00f3\u0142y na ten temat mo\u017cna znale\u017a\u0107 w tutaj<\/a><\/noindex> i tutaj<\/a><\/noindex>.<\/p>\n

Otwieranie plik\u00f3w przy u\u017cyciu flag O_SYNC i O_DSYNC<\/h2>\n

\nWr\u00f3\u0107my do om\u00f3wienia mechanizm\u00f3w Linux, kt\u00f3re zapewniaj\u0105 trwa\u0142e przechowywanie danych. A mianowicie m\u00f3wimy tu o u\u017cyciu flagi O_SYNC<\/code> lub flagi O_DSYNC<\/code> przy otwieraniu plik\u00f3w za pomoc\u0105 wywo\u0142ania systemowego open()<\/a><\/noindex>. Przy tym podej\u015bciu ka\u017cda operacja zapisu danych jest wykonywana tak, jakby po ka\u017cdym poleceniu write()<\/code> systemowi s\u0105 wydawane odpowiednio polecenia fsync()<\/code> i fdatasync()<\/code>. W specyfikacji POSIX<\/a><\/noindex> nazywa si\u0119 to \u201eZako\u0144czeniem integracji pliku zatwierdzonego I\/O\u201d i \u201eZako\u0144czeniem integralno\u015bci danych\u201d. G\u0142\u00f3wn\u0105 zalet\u0105 tego podej\u015bcia jest to, \u017ce w celu zapewnienia integralno\u015bci danych wystarczy wykona\u0107 jedno wywo\u0142anie systemowe, a nie dwa (na przyk\u0142ad \u2014 write()<\/code> i fdatasync()<\/code>). G\u0142\u00f3wn\u0105 wad\u0105 tego podej\u015bcia jest to, \u017ce wszystkie operacje zapisu korzystaj\u0105ce z odpowiedniego deskryptora pliku b\u0119d\u0105 synchronizowane, co mo\u017ce ogranicza\u0107 mo\u017cliwo\u015bci strukturyzacji kodu aplikacji.<\/p>\n

U\u017cycie Direct I\/O z flag\u0105 O_DIRECT<\/h2>\n

\nWywo\u0142anie systemowe open()<\/code> wspiera flag\u0119 O_DIRECT<\/code>, kt\u00f3ra ma na celu, omijaj\u0105c pami\u0119\u0107 podr\u0119czn\u0105 systemu operacyjnego, wykonywanie operacji wej\u015bcia\/wyj\u015bcia, wsp\u00f3\u0142pracuj\u0105c bezpo\u015brednio z dyskiem. Oznacza to, \u017ce w wielu przypadkach polecenia zapisu wydawane przez program b\u0119d\u0105 bezpo\u015brednio przekszta\u0142cane w polecenia dotycz\u0105ce pracy z dyskiem. Jednak w og\u00f3lnym przypadku ten mechanizm nie jest zast\u0105pieniem funkcji fsync()<\/code> lub fdatasync()<\/code>. Chodzi o to, \u017ce sam dysk mo\u017ce od\u0142o\u017cy\u0107 lub buforowa\u0107<\/a><\/noindex> odpowiednie komendy zapisu danych. Co gorsza, w niekt\u00f3rych szczeg\u00f3lnych przypadkach operacje we\/wy wykonywane przy u\u017cyciu flagi O_DIRECT<\/code>, s\u0105 przesy\u0142ane<\/a><\/noindex> do tradycyjnych operacji buforowanych. Naj\u0142atwiej rozwi\u0105za\u0107 ten problem, u\u017cywaj\u0105c w otwieraniu plik\u00f3w tak\u017ce flagi O_DSYNC<\/code>, co oznacza, \u017ce ka\u017cda operacja zapisu b\u0119dzie mia\u0142a wywo\u0142anie fdatasync()<\/code>.<\/p>\n

Okaza\u0142o si\u0119, \u017ce w systemie plik\u00f3w XFS niedawno dodano \u201eszybk\u0105 \u015bcie\u017ck\u0119\u201d dla O_DIRECT|O_DSYNC<\/code>-zapisu danych. Je\u015bli blok jest nadpisywany za pomoc\u0105 O_DIRECT|O_DSYNC<\/code>, to XFS, zamiast zrzuci\u0107 bufor, wykona polecenie FUA-zapisu, je\u015bli urz\u0105dzenie to obs\u0142uguje. Uda\u0142o mi si\u0119 to potwierdzi\u0107, korzystaj\u0105c z narz\u0119dzia blktrace<\/code> w systemie Linux 5.4\/Ubuntu 20.04. Takie podej\u015bcie powinno by\u0107 bardziej efektywne, poniewa\u017c przy jego u\u017cyciu na dysk zapisywana jest minimalna ilo\u015b\u0107 danych i stosowana jest jedna operacja, a nie dwie (zapis i zrzut bufora). Znalaz\u0142em odniesienie do \u0142atk\u0119<\/a><\/noindex> j\u0105dra z 2018 roku, w kt\u00f3rym zrealizowano ten mechanizm. Jest tam dyskusja dotycz\u0105ca zastosowania tej optymalizacji w innych systemach plik\u00f3w, ale o ile mi wiadomo, XFS to jak na razie jedyny system plik\u00f3w, kt\u00f3ry to obs\u0142uguje.<\/p>\n

Funkcja sync_file_range()<\/h2>\n

\nW systemie Linux istnieje wywo\u0142anie systemowe sync_file_range()<\/a><\/noindex>, kt\u00f3re umo\u017cliwia zrzucenie na dysk tylko cz\u0119\u015bci pliku, a nie ca\u0142ego pliku. To wywo\u0142anie inicjuje asynchroniczny zrzut danych i nie czeka na jego zako\u0144czenie. Jednak w dokumentacji do sync_file_range()<\/code> m\u00f3wi si\u0119, \u017ce ta komenda jest \u201ebardzo niebezpieczna\u201d. Nie zaleca si\u0119 jej u\u017cywania. Cechy i niebezpiecze\u0144stwa sync_file_range()<\/code> s\u0105 bardzo dobrze opisane w tym<\/a><\/noindex> materiale. W szczeg\u00f3lno\u015bci, wygl\u0105da na to, \u017ce to wywo\u0142anie u\u017cywa RocksDB do zarz\u0105dzania tym, kiedy j\u0105dro zrzuca \u201ebrudne\u201d dane na dysk. Ale przy tym, dla zapewnienia trwa\u0142ego przechowywania danych, u\u017cywane jest tak\u017ce fdatasync()<\/code>. W kodzie<\/a><\/noindex> RocksDB s\u0105 interesuj\u0105ce komentarze na ten temat. Na przyk\u0142ad, wydaje si\u0119, \u017ce wywo\u0142anie sync_file_range()<\/code> przy u\u017cyciu ZFS nie prowadzi do zrzutu danych na dysk. Do\u015bwiadczenie podpowiada mi, \u017ce kod, kt\u00f3ry u\u017cywany jest rzadko, mo\u017ce zawiera\u0107 b\u0142\u0119dy. Dlatego doradzi\u0142bym, aby nie korzysta\u0107 z tego wywo\u0142ania systemowego bez powa\u017cnej potrzeby.<\/p>\n

Wywo\u0142ania systemowe, kt\u00f3re pomagaj\u0105 zapewni\u0107 trwa\u0142e przechowywanie danych<\/h2>\n

\nDoszed\u0142em do wniosku, \u017ce do wykonywania operacji wej\u015bcia\/wyj\u015bcia, zapewniaj\u0105cych trwa\u0142e przechowywanie danych, mo\u017cna stosowa\u0107 trzy podej\u015bcia. Wszystkie one wymagaj\u0105 wywo\u0142ania funkcji fsync()<\/code> dla katalogu, w kt\u00f3rym utworzono plik. Oto te podej\u015bcia:<\/p>\n

    \n
  1. Wywo\u0142anie funkcji fdatasync()<\/code> lub fsync()<\/code> po funkcji write()<\/code> (lepiej u\u017cywa\u0107 fdatasync()<\/code>).<\/li>\n
  2. Praca z deskryptorem pliku otwartym z flag\u0105 O_DSYNC<\/code> lub O_SYNC<\/code> (lepiej \u2014 z flag\u0105 O_DSYNC<\/code>).<\/li>\n
  3. U\u017cycie polecenia pwritev2()<\/code> z flag\u0105 RWF_DSYNC<\/code> lub RWF_SYNC<\/code> (lepiej \u2014 z flag\u0105 RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Notatki na temat wydajno\u015bci<\/h2>\n

    \nNie przeprowadza\u0142em dok\u0142adnych pomiar\u00f3w wydajno\u015bci r\u00f3\u017cnych mechanizm\u00f3w, kt\u00f3re zbada\u0142em. Zauwa\u017cone przeze mnie r\u00f3\u017cnice w szybko\u015bci ich dzia\u0142ania s\u0105 do\u015b\u0107 niewielkie. Oznacza to, \u017ce mog\u0119 si\u0119 myli\u0107, a przy innych warunkach to samo mo\u017ce da\u0107 inne wyniki. Najpierw opowiem o tym, co bardziej wp\u0142ywa na wydajno\u015b\u0107, a potem o tym, co wp\u0142ywa na ni\u0105 mniej.<\/p>\n

      \n
    1. Nadpisywanie danych pliku jest szybsze ni\u017c do\u0142\u0105czanie danych do pliku (wzrost wydajno\u015bci mo\u017ce wynosi\u0107 od 2 do 100%). Do\u0142\u0105czanie danych do pliku wymaga dokonania dodatkowych zmian w metadanych pliku, nawet po wywo\u0142aniu systemowym fallocate()<\/code>, ale skala tego efektu mo\u017ce si\u0119 zmienia\u0107. Zalecam wywo\u0142a\u0107 fallocate()<\/code> w celu wst\u0119pnego przydzielenia wymaganego miejsca. Nast\u0119pnie to miejsce nale\u017cy jawnie wype\u0142ni\u0107 zerami i wywo\u0142a\u0107 fsync()<\/code>. Dzi\u0119ki temu odpowiednie bloki w systemie plik\u00f3w b\u0119d\u0105 oznaczone jako 'przydzielone', a nie 'nieprzydzielone'. Daje to niewielk\u0105 (oko\u0142o 2%) popraw\u0119 wydajno\u015bci. Ponadto, w przypadku niekt\u00f3rych dysk\u00f3w pierwsza operacja dost\u0119pu do bloku mo\u017ce by\u0107 wolniejsza od innych. Oznacza to, \u017ce wype\u0142nienie miejsca zerami mo\u017ce prowadzi\u0107 do znacznej (oko\u0142o 100%) poprawy wydajno\u015bci. W szczeg\u00f3lno\u015bci mo\u017ce to wyst\u0105pi\u0107 w przypadku dysk\u00f3w AWS EBS<\/a><\/noindex> (to \u2014 dane nieoficjalne, nie mog\u0142em ich potwierdzi\u0107). To samo dotyczy pami\u0119ci GCP Persistent Disk<\/a><\/noindex> (a to \u2014 ju\u017c oficjalne informacj\u0119, potwierdzone testami). Inni specjali\u015bci dokonali takich samych obserwacji<\/a><\/noindex>, dotycz\u0105cych r\u00f3\u017cnych dysk\u00f3w.<\/li>\n
    2. Im mniej wywo\u0142a\u0144 systemowych \u2014 tym wy\u017csza wydajno\u015b\u0107 (wzrost mo\u017ce wynosi\u0107 oko\u0142o 5%). Wydaje si\u0119, \u017ce wywo\u0142anie open()<\/code> z flag\u0105 O_DSYNC<\/code> lub wywo\u0142anie pwritev2()<\/code> z flag\u0105 RWF_SYNC<\/code> szybsze wywo\u0142anie fdatasync()<\/code>. Podejrzewam, \u017ce to dlatego, \u017ce przy takim podej\u015bciu kluczowe jest to, \u017ce do rozwi\u0105zania tego samego zadania konieczne jest wykonanie mniejszej liczby wywo\u0142a\u0144 systemowych (jedno wywo\u0142anie zamiast dw\u00f3ch). Ale r\u00f3\u017cnica w wydajno\u015bci jest bardzo ma\u0142a, wi\u0119c mo\u017cesz ca\u0142kowicie zignorowa\u0107 ten aspekt i u\u017cywa\u0107 w aplikacji tego, co nie skomplikuje jej logiki.<\/li>\n<\/ol>\n

      \nJe\u015bli interesuje Ci\u0119 temat trwa\u0142ego przechowywania danych \u2014 oto kilka przydatnych materia\u0142\u00f3w:<\/p>\n