По сути, я хочу fwrite() n байтов и иметь < n байтов, которые будут записаны на реальном диске, или любые другие артефакты несогласованности могут возникнуть (например, сектора записываются не по порядку).
Я знаю, что могу сделать это на аппаратном уровне с помощью:
- голый металл, дергая за шнур питания ИЛИ
- с виртуализированной ОС, просто выполнив сброс через гипервизор.
.. но мне не нравятся вышеупомянутые случаи, потому что:
- Я не хочу повредить свое оборудование фактической потерей мощности.
- Фактическое моделирование потери мощности является ручным и / или трудным и уродливым для автоматизации.
- Симуляция потери мощности виртуализации лучше, но я думаю, что было бы довольно медленно выполнить 100 запусков с базой данных, ожидая загрузки виртуальной машины и безобразной необходимости строить логику для повторного входа в систему через SSH, пока виртуальная машина не загрузится.
.. поэтому я ищу более быстрое и простое решение для автоматизации.
У меня было несколько идей:
1) Завершить процесс с помощью $ kill -9 dbms_pid
Это, вероятно, не сработает, так как я предполагаю, что все, что указано в fwrite() , добавляется атомарно в буферы, управляемые ядром (это предположение), и после уничтожения процесса ядро, вероятно, просто сбрасывает буферы нормально на диск?
2) Размонтировать файловую систему в середине записи
Я не думаю, что размонтирование работает, когда в файловой системе есть открытые файлы.
3) Расположите файловую систему на устройстве обратной связи, поддерживаемом файлом, и просто прекратите запись в этот файл в точке отключения питания.
Я не думаю, что есть механизм для этого. Переименование файла, вероятно, не останавливает запись в файловую систему, поскольку драйвер обратной петли, вероятно, просто ссылается на индекс или некоторую внутреннюю ссылку.
Размонтирование петлевого устройства, вероятно, имеет ту же проблему, что и невозможность сделать, когда на нем есть открытые файлы.
Копирование с блочного устройства-как-файла может сработать (если только оно не заблокировано для записи, что, вероятно, так и есть), но поскольку копирование содержимого не является атомарной операцией, вероятно, возникнут артефакты, не связанные с отключением питания.
4) Разместите файловую систему поверх LVM и сделайте снимок
Это, наверное, моя самая подходящая идея. Снимок тома LVM является атомарным и может в значительной степени имитировать потерю мощности? Я полагаю, что снятые буферы / страницы не учитываются для моментального снимка (что хорошо для моего моделирования), и я надеюсь, что будут введены те же артефакты, что и при отключении питания, например, содержание fwrite() написано только наполовину?
Будут ли записи, вышедшие из строя, или страницы, записанные на томах LVM, всегда будут применяться по порядку?
У тебя есть другие идеи? Что вы думаете о вариантах? Вы согласны с тем, что 4) это лучшая идея?
Почему я это делаю: в основном, я разрабатываю базу данных, долговечность которой я хотел бы проверить, создав автоматизированный сценарий, который бы прошел через огромный цикл испытаний на пытки, предоставив данные для сохранения и имитируя потерю мощности по крайней мере, диск, а затем проверка того, что никакие зафиксированные данные не были потеряны и что база данных может безопасно восстановиться.