Имитация повреждения файлов в Linux программно? (для проверки прочности БД)

По сути, я хочу, чтобы fwrite() nбайты и < nбайты были записаны на реальном диске, или любые другие артефакты несогласованности могут возникнуть (например, сектора записываются не по порядку).

Я знаю, что могу сделать это на аппаратном уровне с помощью:

• голый металл, дергая за шнур питания ИЛИ
• с виртуализированной ОС, просто выполнив сброс через гипервизор.

.. но мне не нравятся вышеупомянутые случаи, потому что:

• Я не хочу повредить свое оборудование фактической потерей мощности.
• Фактическое моделирование потери мощности является ручным и / или трудным и уродливым для автоматизации.
• Симуляция потери мощности виртуализации лучше, но я думаю, что было бы довольно медленно выполнить 100 запусков с базой данных, ожидая загрузки виртуальной машины и безобразной необходимости строить логику для повторного входа в систему через SSH, пока виртуальная машина не загрузится.

.. поэтому я ищу более быстрое и простое решение для автоматизации.

У меня было несколько идей:

1) убить процесс с $ kill -9 dbms_pid

Это, вероятно, не сработает, так как я предполагаю, что все, что дано, fwrite()добавляется атомарно в буферы, управляемые ядром (это предположение), и после уничтожения процесса ядро, вероятно, просто просто сбрасывает буферы на диск?

2) Размонтировать файловую систему в середине записи

Я не думаю, что размонтирование работает, когда в файловой системе есть открытые файлы.

3) Расположите файловую систему на устройстве обратной связи, поддерживаемом файлом, и просто прекратите запись в этот файл в точке отключения питания.

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

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

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

4) Разместите файловую систему поверх LVM и сделайте снимок

Это, наверное, моя самая подходящая идея. Снимок тома LVM является атомарным и может в значительной степени имитировать потерю мощности? Я полагаю, что снятые буферы / страницы не учитываются для моментального снимка (что хорошо для моего моделирования), и я надеюсь, что будут введены те же артефакты, что и при отключении питания, например, fwrite()содержание будет написано только наполовину?

Будут ли записи, вышедшие из строя, или страницы, записанные на томах LVM, всегда будут применяться по порядку?

У тебя есть другие идеи? Что вы думаете о вариантах? Вы согласны с тем, что 4) это лучшая идея?

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