Специальный файл, вызывающий ошибку ввода / вывода

Я хочу автоматически проверить, реагирует ли программа должным образом, если не удается прочитать необходимый файл БД SQLite (что приводит к ошибке ввода-вывода). Именно это произошло несколько дней назад у клиента. Мы исправили это вручную, но теперь я хочу создать автоматический код, чтобы исправить это, и мне нужен доступ к поврежденному файлу, чтобы проверить это.

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

Некоторые похожие файлы (IMO) будут:

• /dev/full который всегда говорит "Нет свободного места на устройстве", если вы пытаетесь написать его
• /dev/null и /dev/zero

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

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

Вы можете использовать dmsetupдля создания устройства сопоставления устройств, используя цели errorили flakeyдля имитации сбоев.

dmsetup create test --table '0 123 flakey 1 0 /dev/loop0'

Где 123 - длина устройства, в секторах, а / dev / loop0 - исходное устройство, на котором вы хотите симулировать ошибки. Для ошибки вам не нужны последующие аргументы, поскольку она всегда возвращает ошибку.

Ответы на этот вопрос уже есть о переполнении стека и сбое сервера, но некоторые методы отсутствовали. Чтобы упростить жизнь, вот список виртуальных устройств / блочных устройств Linux / файловой системы Linux / библиотеки пользовательских пространств ввода-вывода Linux:

• Используйте устройства Device Mapper error / flakey / delay / dm-dust для возврата ошибок / повреждений или задержки / разделения ввода-вывода на синтезированное блочное устройство (ядро, требует, чтобы ядро ​​было собрано с поддержкой устройства отображения, соответствующие дополнительные модули отображения устройства ( dm-dust доступен только для ядра> = 5.2) и иметь биты пространства пользователя для устройства отображения).
• Используйте ошибочную индивидуальность md для выполнения периодического ввода неисправности на синтезированном блочном устройстве. См. --layoutПараметр справочной страницы mdadm, чтобы узнать, как его настроить (биты ядра и ядра mdadm).
• Используйте libfiu для внедрения ошибок в вызовы API POSIX (пользовательское пространство можно использовать с LD_PRELOAD).
• Используйте инжектор ошибок ядра Linux, чтобы внедрить ошибку в базовое блочное устройство (ядро требует, чтобы ядро ​​было скомпилировано FAIL_MAKE_REQUEST=y).
• Использование SystemTap для инъекции ошибок (ядро требует, чтобы ядро ​​было собрано с большим количеством вещей ).
• Внедрить ошибки файловой системы, используя CharybdeFS или PetardFS (пользовательское пространство через FUSE).
• Создайте синтезированное блочное устройство с помощью драйвера Linux scsi_debug, который выполняет внедрение ошибок (ядро).
• Запустите вашу систему в QEMU и используйте QEMU для ввода ошибок блочных устройств с помощью драйвера blkdebug (VM).
• Создайте синтезированное блочное устройство с помощью опций устройства null_blk для ввода сбоев (ядро> = 4.14, но такие опции, как вероятности тайм-аута, появились только до 4.17 и требуют, чтобы ядро ​​было собрано BLK_DEV_NULL_BLK_FAULT_INJECTION=y).
• Создайте синтезированное сетевое блочное устройство, которое подается на хост через фильтры NBDkit, такие как delayили, errorа затем подключите к нему блочное устройство nbd-client(биты ядра + NBD, пространство> = 4.18, построенное с поддержкой NBD, nbdclient> = 3.18 и nbdkit> = 1.8.1 рекомендуется - см. Демонстрационное видео NBDKit около 20-минутной отметки).

Дополнительный факт: в SQLite есть драйвер VFS для имитации ошибок, поэтому он может обеспечить хорошее тестовое покрытие.

Связанный:

• Как я могу симулировать неисправный диск во время тестирования?
• Имитировать неисправное блочное устройство с ошибками чтения?
• Создать ошибку чтения
• Умышленно вызывать ошибку ввода-вывода в Linux?

Вы хотите механизм ввода неисправности для ввода / вывода.

В Linux есть метод, который не требует предварительной настройки и генерирует необычную ошибку (не EIO «Ошибка ввода-вывода», а ESRCH «Нет такого процесса»):

cat /proc/1234/mem

где 1234 - PID процесса, запущенного от имени того же пользователя, что и тестируемый процесс, но не самого процесса. Кредиты rubasov для мышления о /proc/$pid/mem.

Если вы используете PID самого процесса, вы получаете EIO, но только если вы читаете из области, которая не отображается в памяти процесса. Первая страница никогда не отображается, поэтому нормально, если вы читаете файл последовательно, но не подходит для процесса базы данных, который ищет непосредственно в середине файла.

С некоторыми дополнительными настройками в качестве пользователя root вы можете использовать устройство отображения карт для создания файлов с допустимыми секторами и поврежденными секторами.

Другой подход заключается в реализации небольшой файловой системы FUSE . EIO - это код ошибки по умолчанию, когда драйвер вашей файловой системы пользователя делает что-то не так, так что это легко сделать. Оба Perl и Python привязки поставляются с примерами , чтобы начать работу, вы можете быстро написать файловую систему , которая в основном зеркала существующие файлы , но впрыскивает EIO в тщательно выбранных местах. Существует такая файловая система: petardfs ( статья ), я не знаю, насколько хорошо она работает из коробки.

Еще один метод - это LD_PRELOADобертка. Существующим является Libfiu (внедрение ошибок в пользовательском пространстве). Он работает путем предварительной загрузки библиотеки, которая перегружает вызовы API POSIX. Вы можете написать простые директивы или произвольный C-код для переопределения нормального поведения.

Решение намного проще, если можно использовать файл устройства как «файл с ошибками ввода-вывода». Мое предложение для тех случаев, когда обычный файл должен иметь такие ошибки.

> dd if=/dev/zero of=/path/to/ext2.img bs=10M count=10
> losetup /dev/loop0 /path/to/ext2.img
> blockdev --getsz /dev/loop0
204800
> echo "0 204800 linear /dev/loop0 0" | dmsetup create sane_dev
> mke2fs /dev/mapper/sane_dev # ext2 reicht
> mount -t ext2 /dev/mapper/sane_dev /some/where
> dd if=/dev/zero of=/some/where/unreadable_file bs=512 count=4
> hdparm --fibmap /some/where/unreadable_file
/mnt/tmp/unreadable_file:
 filesystem blocksize 1024, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0       2050       2053          4
> umount /dev/mapper/sane_dev
> dmsetup remove sane_dev
> start_sector=$((204800-2053-1))
> echo $'0 2053 linear /dev/loop0 0\n2053 1 error\n2054 '"${start_sector} linear /dev/loop0 2054" | 
>   dmsetup create error_dev
> mount -t ext2 /dev/mapper/error_dev /some/where
> cat /some/where/unreadable_file # 3rd sector of file is unreadable
cat: /some/where/unreadable_file: Input/output error

Я должен признать, что я немного запутался, потому что мне не удалось прочитать отдельные сектора из этого файла без ошибки (с dd .. seek=...). Может быть, это проблема упреждающего чтения.

Вы можете использовать CharybdeFS, которая была сделана именно для этой цели.

Это сквозная файловая система с предохранителями типа PetardFS, но гораздо более настраиваемая.

Смотрите кулинарную книгу CharybdeFS здесь: http://www.scylladb.com/2016/05/02/fault-injection-filesystem-cookbook/

Он достаточно продвинут, чтобы проверить базу данных.