2

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

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

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

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

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

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

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

1) Завершить процесс с помощью $ kill -9 dbms_pid

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

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

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

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

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

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

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

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

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

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


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

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

1 ответ1

0

Предположительно, это диски SATA, которые потенциально могут быть заменены в горячем режиме.

Так что сделайте свою домашнюю работу: горячую замену вашей системы, чтобы вы не выпускали {волшебный дым}, а затем извлекаете диск во время испытаний на пытки.

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

Некоторое дальнейшее чтение: https://serverfault.com/questions/690609/

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .