Pisanie programów radzących sobie z błędami we / wy powodującymi utratę zapisów w systemie Linux

TL; DR: Jeśli jądro Linuksa utraci buforowany zapis we / wy , czy jest jakiś sposób, aby aplikacja się dowiedziała?

Wiem, że potrzebujesz fsync()pliku (i jego katalogu nadrzędnego) dla trwałości . Pytanie brzmi: jeśli jądro traci brudne bufory oczekujące na zapis z powodu błędu we / wy, w jaki sposób aplikacja może to wykryć i odzyskać lub przerwać?

Pomyśl o aplikacjach baz danych itp., Gdzie kolejność i trwałość zapisu mogą być kluczowe.

Zagubione zapisy? W jaki sposób?

Warstwa blok Czy Linux Kernel jest w pewnych okolicznościach stracić buforowane żądań I / O, które zostały wprowadzone z powodzeniem write(), pwrite()itp, z błędem jak:

Buffer I/O error on device dm-0, logical block 12345
lost page write due to I/O error on dm-0

(Zobacz end_buffer_write_sync(...)i end_buffer_async_write(...)wfs/buffer.c środku).

W nowszych jądrach błąd będzie zawierał „utracony asynchroniczny zapis strony” , na przykład:

Buffer I/O error on dev dm-0, logical block 12345, lost async page write

Ponieważ aplikacja write()została już zwrócona bez błędów, wydaje się, że nie ma możliwości zgłoszenia błędu z powrotem do aplikacji.

Wykrywanie ich?

Nie jestem zaznajomiony ze źródłami jądra, ale myślę , że ustawia AS_EIObufor, który nie został zapisany, jeśli wykonuje zapis asynchroniczny:

    set_bit(AS_EIO, &page->mapping->flags);
    set_buffer_write_io_error(bh);
    clear_buffer_uptodate(bh);
    SetPageError(page);

ale nie jest dla mnie jasne, czy i w jaki sposób aplikacja może się o tym dowiedzieć, kiedy później fsync()będzie plik, aby potwierdzić, że znajduje się na dysku.

Wygląda na to, że wait_on_page_writeback_range(...)wmm/filemap.c potędze, do_sync_mapping_range(...)wfs/sync.c którym jest sprawdzany sys_sync_file_range(...). Zwraca, -EIOjeśli nie można zapisać jednego lub więcej buforów.

Jeśli, jak się domyślam, rozprzestrzeni się to do fsync()wyniku, to jeśli aplikacja panikuje i wyskakuje, jeśli otrzyma błąd we / wy fsync()i wie, jak ponownie wykonać swoją pracę po ponownym uruchomieniu, to powinno być wystarczającym zabezpieczeniem?

Prawdopodobnie nie ma sposobu, aby aplikacja wiedziała, które przesunięcia bajtów w pliku odpowiadają utraconym stronom, aby mogła je przepisać, jeśli wie jak, ale jeśli aplikacja powtórzy całą swoją oczekującą pracę od ostatniego udanego fsync()pliku, a to przepisuje wszelkie brudne bufory jądra odpowiadające utraconym zapisom w pliku, które powinny wyczyścić wszelkie flagi błędów we / wy na utraconych stronach i pozwolić na zakończenie następnej fsync()- prawda?

Czy są zatem inne, nieszkodliwe okoliczności, do których fsync()mogą powrócić, w -EIOktórych ratowanie i ponawianie pracy byłoby zbyt drastyczne?

Czemu?

Oczywiście takie błędy nie powinny się zdarzyć. W tym przypadku błąd wynikał z niefortunnej interakcji między dm-multipathustawieniami domyślnymi sterownika a kodem rozpoznawczym używanym przez sieć SAN do zgłaszania niepowodzenia alokacji alokacji elastycznej. Ale to nie jedyna okoliczność, w której mogą się zdarzyć - widziałem również raporty o tym, na przykład z cienkiego aprowizowanego LVM, używanego przez libvirt, Docker i inne. Krytyczna aplikacja, taka jak baza danych, powinna próbować radzić sobie z takimi błędami, zamiast działać na ślepo, jakby wszystko było w porządku.

Jeśli jądro uważa, że ​​można stracić zapisy bez umierania z powodu paniki jądra, aplikacje muszą znaleźć sposób, aby sobie z tym poradzić.

Praktyczny wpływ jest taki, że znalazłem przypadek, w którym problem wielościeżkowy z SAN spowodował utratę zapisów, które wylądowały, powodując uszkodzenie bazy danych, ponieważ DBMS nie wiedział, że jego zapisy nie powiodły się. Nie śmieszne.

fsync()zwraca, -EIOjeśli jądro utraciło zapis

(Uwaga: wczesne części odnoszą się do starszych jąder; zaktualizowane poniżej, aby odzwierciedlały nowoczesne jądra)

Wygląda na to, że asynchroniczny zapis bufora w przypadku end_buffer_async_write(...)awarii ustawia -EIOflagę na stronie uszkodzonego buforu dla pliku :

set_bit(AS_EIO, &page->mapping->flags);
set_buffer_write_io_error(bh);
clear_buffer_uptodate(bh);
SetPageError(page);

która jest wykrywana przez wait_on_page_writeback_range(...)co wywołana przez do_sync_mapping_range(...)co wywołana przez sys_sync_file_range(...)co wywołana przez sys_sync_file_range2(...)do realizacji połączenia biblioteki C fsync().

Ale tylko raz!

Ten komentarz na sys_sync_file_range

168  * SYNC_FILE_RANGE_WAIT_BEFORE and SYNC_FILE_RANGE_WAIT_AFTER will detect any
169  * I/O errors or ENOSPC conditions and will return those to the caller, after
170  * clearing the EIO and ENOSPC flags in the address_space.

sugeruje, że gdy fsync()zwróci -EIOlub (nieudokumentowane na stronie podręcznika) -ENOSPC, wyczyści stan błędu, więc kolejny fsync()poinformuje o sukcesie, nawet jeśli strony nigdy nie zostały zapisane.

Oczywiście wait_on_page_writeback_range(...) czyści bity błędów podczas ich testowania :

301         /* Check for outstanding write errors */
302         if (test_and_clear_bit(AS_ENOSPC, &mapping->flags))
303                 ret = -ENOSPC;
304         if (test_and_clear_bit(AS_EIO, &mapping->flags))
305                 ret = -EIO;

Więc jeśli aplikacja spodziewa się, że może spróbować ponownie, fsync()aż się powiedzie i będzie ufać, że dane znajdują się na dysku, to jest strasznie źle.

Jestem prawie pewien, że to jest źródło uszkodzenia danych, które znalazłem w DBMS. Ponawia próbę fsync()i myśli, że wszystko będzie dobrze, gdy się powiedzie.

Czy to jest dozwolone?

Dokumentacja POSIX / SuSfsync() tak naprawdę nie określa tego w żaden sposób:

Jeśli funkcja fsync () zawiedzie, nie ma gwarancji, że zaległe operacje we / wy zostaną zakończone.

Strona podręcznika systemu Linux pofsync() prostu nie mówi nic o tym, co dzieje się w przypadku awarii.

Wygląda więc na to, że znaczenie fsync()błędów brzmi „nie wiem, co się stało z twoimi zapisami, mogło zadziałać lub nie, lepiej spróbuj ponownie, aby się upewnić”.

Nowsze jądra

W end_buffer_async_writezestawach 4.9 -EIOna stronie, po prostu przez mapping_set_error.

    buffer_io_error(bh, ", lost async page write");
    mapping_set_error(page->mapping, -EIO);
    set_buffer_write_io_error(bh);
    clear_buffer_uptodate(bh);
    SetPageError(page);

Po stronie synchronizacji myślę, że jest podobnie, chociaż struktura jest teraz dość złożona do naśladowania. filemap_check_errorsw mm/filemap.cteraz robi:

    if (test_bit(AS_EIO, &mapping->flags) &&
        test_and_clear_bit(AS_EIO, &mapping->flags))
            ret = -EIO;

co ma podobny efekt. Wydaje się, że wszystkie kontrole błędów przechodzą, filemap_check_errorsco przeprowadza test i wyczyszczenie:

    if (test_bit(AS_EIO, &mapping->flags) &&
        test_and_clear_bit(AS_EIO, &mapping->flags))
            ret = -EIO;
    return ret;

Używam btrfsna moim laptopie, ale kiedy tworzę ext4pętlę zwrotną do testowania /mnt/tmpi ustawiam na niej sondę perf:

sudo dd if=/dev/zero of=/tmp/ext bs=1M count=100
sudo mke2fs -j -T ext4 /tmp/ext
sudo mount -o loop /tmp/ext /mnt/tmp

sudo perf probe filemap_check_errors

sudo perf record -g -e probe:end_buffer_async_write -e probe:filemap_check_errors dd if=/dev/zero of=/mnt/tmp/test bs=4k count=1 conv=fsync

Znajduję następujący stos wywołań w perf report -T:

        ---__GI___libc_fsync
           entry_SYSCALL_64_fastpath
           sys_fsync
           do_fsync
           vfs_fsync_range
           ext4_sync_file
           filemap_write_and_wait_range
           filemap_check_errors

Czytanie sugeruje, że tak, nowoczesne jądra zachowują się tak samo.

Wydaje się to oznaczać, że jeśli fsync()(lub przypuszczalnie write()lub close()) powróci -EIO, plik jest w jakimś niezdefiniowanym stanie między ostatnim pomyślnym fsync()d lub close()d, a ostatnim write()dziesięcioma stanami.

Test

Zaimplementowałem przypadek testowy, aby zademonstrować to zachowanie .

Implikacje

DBMS może sobie z tym poradzić, uruchamiając odzyskiwanie po awarii. Jak, u licha, ma sobie z tym radzić zwykła aplikacja użytkownika? fsync()Strona człowiek nie daje ostrzeżenie, że to znaczy „fsync-if-you-feel-jak-to”, a ja się spodziewać wiele z aplikacji nie będzie dobrze poradzić sobie z tym zachowaniem.

Zgłaszanie błędów

• https://bugzilla.kernel.org/show_bug.cgi?id=194755
• https://bugzilla.kernel.org/show_bug.cgi?id=194757

Dalsza lektura

Witryna lwn.net poruszyła ten temat w artykule „Ulepszona obsługa błędów w warstwie bloków” .

Wątek z listą dyskusyjną postgresql.org .

Ponieważ metoda write () aplikacji zwróciła już bez błędu, wydaje się, że nie ma możliwości zgłoszenia błędu z powrotem do aplikacji.

Nie zgadzam się. writemoże powrócić bez błędu, jeśli zapis jest po prostu w kolejce, ale błąd zostanie zgłoszony podczas następnej operacji, która będzie wymagała rzeczywistego zapisu na dysku, to znaczy w następnym fsync, prawdopodobnie następnym zapisie, jeśli system zdecyduje się opróżnić pamięć podręczną io godzinie przynajmniej przy ostatnim zamknięciu pliku.

Dlatego tak ważne jest, aby aplikacja przetestowała zwracaną wartość close, aby wykryć ewentualne błędy zapisu.

Jeśli naprawdę potrzebujesz umieć sprytnie przetwarzać błędy, musisz założyć, że wszystko, co zostało napisane od ostatniego sukcesu, fsync mogło się nie udać , a przynajmniej coś zawiodło.

write(2) zapewnia mniej niż się spodziewasz. Strona podręcznika jest bardzo otwarta na temat semantyki udanego write()połączenia:

Pomyślny powrót z write()adresu nie gwarantuje, że dane zostały zapisane na dysku. W rzeczywistości w niektórych błędnych implementacjach nie gwarantuje to nawet pomyślnego zarezerwowania miejsca na dane. Jedynym sposobem, aby się upewnić, jest wywołanie fsync(2) po zakończeniu zapisywania wszystkich danych.

Możemy wywnioskować, że sukces write()oznacza jedynie, że dane dotarły do ​​funkcji buforowania jądra. Jeśli utrwalanie bufora nie powiedzie się, późniejszy dostęp do deskryptora pliku zwróci kod błędu. To może być ostateczność close(). Strona podręcznika closewywołania systemowego (2) zawiera następujące zdanie:

Jest całkiem możliwe, że błędy w poprzedniej write(2) operacji są najpierw zgłaszane w funkcji final close().

Jeśli Twoja aplikacja musi utrwalać zapisywanie danych, musi używać fsync/ fsyncdataregularnie:

fsync()przesyła („opróżnia”) wszystkie zmodyfikowane dane w rdzeniu (tj. zmodyfikowane strony pamięci podręcznej bufora) pliku, do którego odwołuje się deskryptor pliku fd, na urządzenie dyskowe (lub inne trwałe urządzenie magazynujące), aby można było odzyskać wszystkie zmienione informacje nawet po awarii lub ponownym uruchomieniu systemu. Obejmuje to zapisywanie lub opróżnianie pamięci podręcznej dysku, jeśli jest obecna. Połączenie jest blokowane do momentu, gdy urządzenie zgłosi, że transfer został zakończony.

Użyj flagi O_SYNC podczas otwierania pliku. Zapewnia zapis danych na dysku.

Jeśli to cię nie zadowoli, nic nie będzie.

Sprawdź zwracaną wartość zamknięcia. close może się nie powieść, podczas gdy buforowane zapisy wydają się udać.