LINUX.ORG.RU

mmap и ошибки записи на диск

 ,


0

2

Последние пару недель не могу найти ответ на вопрос, что же будет, если при записи mmap-нутого файла произойдет ошибка блочного устройства? Как с точки зрения приложения будет выглядеть ошибка (SIGBUS?), в какой момент она появится и как ее правильно обработать?

Как ты собрался программно обрабатывать ошибки железа, кстати?

anonymous ()

Как с точки зрения приложения будет выглядеть ошибка (SIGBUS?)

https://stackoverflow.com/a/54371304

I/O errors on the underlying file (e.g. its removable drive is unplugged or optical media is ejected, disk full when writing, etc.) while accessing its mapped memory are reported to the application as the SIGSEGV/SIGBUS signals on POSIX, and the EXECUTE_IN_PAGE_ERROR structured exception on Windows. All code accessing mapped memory must be prepared to handle these errors, which don't normally occur when accessing memory.

в какой момент она появится и как ее правильно обработать?

Появится при попытке прочитать что-то. Как обрабатывать - через навешивания обработчика на сигнал, man 2 signal.

SZT ★★★★★ ()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от SZT

Появится при попытке прочитать что-то

Ну с чтением-то понятно, а с записью как? dirty page ведь записываться на диск будет когда ядру угодно.

kawaii_neko ★★★★ ()

fsync вернёт код ошибки.

Гугли postgresql fsync. TL;DR: история о том что postgresql обрабатывал это неправильно и как надо. POSIX не говорит что надо делать в случае ошибки, на разных системах, разных ФС и даже на разных версиях ядра по-разному.

NeXTSTEP ★★ ()
Ответ на: комментарий от NeXTSTEP

fsync вернёт код ошибки.

Тут фокус в том, что fsync необязательно будет сбрасывать на диск все. Ну т.е. возможна такая ситуация, что есть в программе memory mapped файл, который попал на бэдблоки, в который что-то та программа записала, потом корректно завершила свою работу (сделав даже fsync!) но на диск это состояние записано не было. И оно может быть записано на диск спустя какое-то время, или при отмонтировании.

https://blog.httrack.com/blog/2013/11/15/everything-you-always-wanted-to-know...

But things are sometimes a bit obscure on the implementation side :

Linux/ext3: If the underlying hard disk has write caching enabled, then the data may not really be on permanent storage when fsync() / fdatasync() return. (do’h!)

Linux/ext4: The fsync() implementations in older kernels and lesser used filesystems does not know how to flush disk caches. (do’h!) – issue adressed quite recently

SZT ★★★★★ ()
Ответ на: комментарий от SZT

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

SZT ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.