Написание программ для устранения ошибок ввода-вывода, вызывающих потерю записи в Linux

TL; DR: Если ядро ​​Linux теряет буферизованную запись ввода-вывода , есть ли способ для приложения узнать?

Я знаю, что вам нужен fsync()файл (и его родительский каталог) для долговечности . Вопрос в том, теряет ли ядро ​​грязные буферы, ожидающие записи, из-за ошибки ввода-вывода, как приложение может обнаружить это и восстановить или прервать работу?

Подумайте о приложениях баз данных и т. Д., Где порядок записи и надежность записи могут иметь решающее значение.

Забыли пишет? Как?

Блок слой ли ядро в некоторых обстоятельствах теряют буферном запросы ввода / вывода , которые были успешно представленные write(), и pwrite()т.д., с сообщением об ошибке , как:

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

(Смотрите end_buffer_write_sync(...)и end_buffer_async_write(...)вfs/buffer.c ).

В более новых ядрах вместо этого ошибка будет содержать "потерянную запись асинхронной страницы" , например:

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

Поскольку приложение write()уже вернулось без ошибок, похоже, нет способа сообщить об ошибке обратно в приложение.

Обнаружить их?

Я не так хорошо знаком с исходными кодами ядра, но думаю, что он устанавливает AS_EIOбуфер, который не может быть записан, если он выполняет асинхронную запись:

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

но мне неясно, может ли приложение узнать об этом и каким образом, когда оно позже отправит fsync()файл, чтобы подтвердить его наличие на диске.

Похоже, wait_on_page_writeback_range(...)вmm/filemap.c мощи, do_sync_mapping_range(...)вfs/sync.c которой зовут очередь sys_sync_file_range(...). Он возвращается, -EIOесли не удалось записать один или несколько буферов.

Если, как я предполагаю, это распространяется на fsync()результат, то, если приложение паникует и выходит из строя, если оно получает ошибку ввода-вывода fsync()и знает, как заново выполнить свою работу при перезапуске, этого должно быть достаточной защиты?

По-видимому, у приложения нет способа узнать, какие байтовые смещения в файле соответствуют потерянным страницам, чтобы оно могло их переписать, если оно знает как, но если приложение повторяет всю свою ожидающую работу с момента последнего успешного fsync()файла, и это перезаписывает любые грязные буферы ядра, соответствующие потерянным операциям записи в файл, которые должны очистить все флаги ошибок ввода-вывода на потерянных страницах и позволить fsync()завершиться следующей, верно?

Существуют ли какие-либо другие, безобидные обстоятельства, при которых fsync()может произойти возвращение, -EIOкогда спасение и повторная работа были бы слишком радикальными?

Зачем?

Конечно, таких ошибок быть не должно. В этом случае ошибка возникла из-за неудачного взаимодействия между dm-multipathнастройками драйвера по умолчанию и сенсорным кодом, используемым SAN для сообщения о невозможности выделения хранилища с тонким предоставлением. Но это не единственное обстоятельство, при котором они могут произойти - я также видел отчеты об этом, например, из LVM с тонкой подготовкой, который используется libvirt, Docker и другими. Важное приложение, такое как база данных, должно пытаться справиться с такими ошибками, а не слепо продолжать работу, как будто все в порядке.

Если ядро считает, что можно потерять запись и не умереть из-за паники ядра, приложения должны найти способ справиться с этим.

Практическое влияние состоит в том, что я обнаружил случай, когда проблема с несколькими путями в SAN вызвала потерянные записи, которые привели к повреждению базы данных, потому что СУБД не знала, что ее запись была неудачной. Не смешно.

fsync()возвращается, -EIOесли ядро ​​потеряло запись

(Примечание: ранняя часть ссылается на старые ядра; обновлено ниже, чтобы отразить современные ядра)

Похоже, что асинхронная запись буфера при end_buffer_async_write(...)сбоях устанавливает -EIOфлаг на странице сбойного грязного буфера для файла :

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

который затем обнаруживается , wait_on_page_writeback_range(...)как вызывается do_sync_mapping_range(...)при вызове , sys_sync_file_range(...)как вызывается sys_sync_file_range2(...)для выполнения вызова библиотеки С fsync().

Но только один раз!

Этот комментарий к 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.

предполагает, что при fsync()возврате -EIOили (недокументированном на странице руководства) -ENOSPCон очистит состояние ошибки, поэтому последующий fsync()сообщит об успехе, даже если страницы никогда не были написаны.

Конечно, wait_on_page_writeback_range(...) при тестировании биты ошибок очищаются :

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;

Поэтому, если приложение ожидает, что оно может повторять попытку fsync()до тех пор, пока оно не увенчается успехом, и полагает, что данные находятся на диске, это ужасно неправильно.

Я почти уверен, что это источник повреждения данных, который я обнаружил в СУБД. Он пытается повторить попытку fsync()и думает, что все будет хорошо, когда ему это удастся.

Это разрешено?

Документы POSIX / SuS наfsync() самом деле не указывают этого в любом случае:

Если функция fsync () дает сбой, выполнение невыполненных операций ввода-вывода не гарантируется.

На странице руководства Linuxfsync() ничего не говорится о том, что происходит в случае сбоя.

Похоже, что смысл fsync()ошибок - «не знаю, что случилось с вашими записями, возможно, сработало или нет, лучше попробуйте еще раз, чтобы убедиться».

Новые ядра

На 4.9 end_buffer_async_writeнаборы -EIOна страничке, просто через 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);

Что касается синхронизации, я думаю, что это похоже, хотя структура теперь довольно сложна. filemap_check_errorsв mm/filemap.cнастоящее время делает:

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

который имеет примерно такой же эффект. Кажется, что все проверки ошибок проходят через filemap_check_errorsпроверку и очистку:

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

Я использую btrfsна своем ноутбуке, но когда я создаю ext4шлейф для тестирования /mnt/tmpи настраиваю на нем датчик производительности:

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

Я нахожу следующий стек вызовов 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

Читка предполагает, что да, современные ядра ведут себя так же.

Похоже, это означает, что если fsync()(или предположительно write()или close()) возвращается -EIO, файл находится в каком-то неопределенном состоянии между тем, когда вы в последний раз успешно fsync()d или close()d, и его последним write()состоянием десять.

Контрольная работа

Я реализовал тестовый пример, чтобы продемонстрировать это поведение .

Последствия

СУБД может справиться с этим путем восстановления после сбоя. Как, черт возьми, обычное пользовательское приложение должно с этим справиться? На fsync()странице руководства нет предупреждений, что это означает «fsync-if-you-feel-like-it», и я ожидаю, что многие приложения не справятся с таким поведением.

Отчеты об ошибках

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

дальнейшее чтение

lwn.net затронул это в статье «Улучшенная обработка ошибок блочного уровня» .

Тема списка рассылки postgresql.org .

Поскольку функция write () приложения уже вернулась без ошибок, похоже, нет способа сообщить об ошибке обратно в приложение.

Я не согласен. writeможет вернуться без ошибки, если запись просто поставлена ​​в очередь, но об ошибке будет сообщено при следующей операции, которая потребует фактической записи на диск, то есть при следующей fsync, возможно, при следующей записи, если система решит очистить кеш и при минимум на последний файл закрыть.

Это причина, по которой приложению важно проверить возвращаемое значение close для обнаружения возможных ошибок записи.

Если вам действительно нужна умная обработка ошибок, вы должны исходить из предположения, что все, что было написано с момента последнего успешного выполнения, fsync могло дать сбой и что во всем этом по крайней мере что-то не удалось.

write(2) дает меньше, чем вы ожидаете. Страница руководства очень открыта о семантике успешного write()вызова:

Успешный возврат из write()не дает никаких гарантий, что данные были зафиксированы на диске. Фактически, в некоторых реализациях с ошибками это даже не гарантирует, что пространство было успешно зарезервировано для данных. Единственный способ быть уверенным - это вызвать fsync(2) после того, как вы закончите запись всех своих данных.

Мы можем сделать вывод, что успешное выполнение write()означает просто, что данные достигли средств буферизации ядра. Если сохранить буфер не удается, последующий доступ к дескриптору файла вернет код ошибки. Это может быть последнее средство close(). Страница руководства closeсистемного вызова (2) содержит следующее предложение:

Вполне возможно, что об ошибках предыдущей write(2) операции сначала сообщается в final close().

Если вашему приложению необходимо сохранить данные, напишите, оно должно использовать fsync/ fsyncdataна регулярной основе:

fsync()передает («сбрасывает») все измененные внутренние данные (т.е. измененные страницы буферного кэша для) файла, на который ссылается файловый дескриптор fd, на дисковое устройство (или другое постоянное запоминающее устройство), чтобы можно было получить всю измененную информацию даже после сбоя системы или перезагрузки. Сюда входит запись или очистка дискового кеша, если таковой имеется. Вызов блокируется, пока устройство не сообщит, что передача завершена.

Используйте флаг O_SYNC при открытии файла. Это обеспечивает запись данных на диск.

Если это вас не удовлетворит, ничего не будет.

Проверьте возвращаемое значение close. close может завершиться ошибкой, тогда как буферизованная запись кажется успешной.