Задать вопрос

Как симулировать сбои в файловой системе?

Посоветуйте куда копать если хочу проверить свою программу в условиях сбоев файловой системы? Может есть уже устоявшиеся готовые файловые решения
Скажем иноды закончились или файлы закоррапчены
  • Вопрос задан
  • 522 просмотра
Подписаться 4 Простой 1 комментарий
Пригласить эксперта
Ответы на вопрос 4
@rPman
Гугл qemu hardware failure simulation.

Также дополнительно добавляй тесты на случайное изменение в кластерах файловой системы просто скриптом, причем не в этой же vm, а подключив один и тот же диск к двум машинами, что бы учесть влияние Кеша

Тесты проводить автоматические, очень много
Ответ написан
Комментировать
jcmvbkbc
@jcmvbkbc
"I'm here to consult you" © Dogbert
Как симулировать сбои в файловой системе? … Может есть уже устоявшиеся готовые файловые решения

В тегах linux, у него есть встроенный механизм fault injection.
Ответ написан
Комментировать
trapwalker
@trapwalker
Программист, энтузиаст
куда копать если хочу проверить свою программу в условиях сбоев файловой системы

Копать надо в сторону документации к своему языку программирования, к библиотекам, которыми вы взаимодействуете с файлами.
Нужно делать аудит кода, понимать какие ошибки возможны в том или ином месте, в конкретных вызовах системных API прямых или косвенных. Эмулировать можно как обычно моками. Просто бросаете все возможные ошибки в моках и смотрите на реакцию тестов. Да, нужны юнит-тесты. Нужно правильно декомпозировать задачи, чтобы их легко можно было тестировать по частям, чтобы прозрачно было чем могут обернуться те или иные unhandled исключения.
Почитайте про Gracefull Degradation, про иммутабельность, журналирование и прочее, что может пригодиться для разработки надёжного кода и архитектуры.
А вы пытаетесь стрелять из ружья дробью по автомобилю, чтобы проверить его надёжность. Это не системный подход.
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
Есть два подхода.

Нанести повреждения сырой файловой системе. Под суперпользователем открыть диск как блочное устройство
(файл по сути) и случайным образом внести изменения в случайные блоки (тут надо владеть информацией о размере блока) 512 байт или 4К или еще какие-то возможны варианты. Записать рандомный шум по сути. Только не трогай первый блок. Там может быть вайжная инфа о файловой системе. Иначе вообще не смонтируешь .. ну хотя может для тебя это тоже кейс.

Если изменение будет попадать в журналы - то они автоматом исправятся при старте. Насколько я помню ext4 хранит копии журналов в разных частях диска. Если изменения попадают внутрь тела файла то это мы не исправим никак. С точки зрения структуры ФС - все выглядит валидно. Структура - цела. Значит чекинг ничего не заметит.

Для некоторых параноидально-защищенных файловых систем (zfs) изменения в теле файла будут детектированы на основе контрольных сумм. Насколько я помню zfs пишет их для каждого файла. Но исправлены не будут
скорее всего. Избыточной информации для исправления нету.

UPD: Тут надо смотреть как собраны программные зеркала этой системы. Возможно исправить все таки можно но там будут куча условий. Целое дерево условие если это то это и так далее. Короче квест.

Вообще очень сильно зависит от цели задачи. И от чего мы пытаемся защититься. Если ты меняешь первый блок файловой.

Тоесть эксперимент похож на слепую стрельбу из пистолета в живого человека. Смотря куда попал. Если в башку - то смерть. Если там в мясо - то можно подлечить как-то.

Второй подход. Рассматривать обычный API файловой системы. Здесь можно просто проверить что будет когда inodes закончились. Ивестно что каждый файл (не hard-link) создает ровно 1 inode в таблице нодов. И эта таблица ограничена в ext3/ext4 кажется. Можно создавать миллионы файлов имеющих нулевой размер и мы постепенно заполним эту таблицу и получим какую-то ошибку. Эта ошибка технически имеет онлайн решение для XFS (там можно на ходу растягивать ФС и таблицы). Для ext3 нужно отмонтировать и что-то сделать в оффлайне.

Про коррапченые файлы мы уже говорили. Если это вопрос файловой системы - то она не видит ничего скорее всего. Рандомное изменение тела файла - это легальная операция файлового API. Увидит только софт который будет этот файл открывать. Например word документ не откроется. JPEG картинка может открыться наполовину. Будем видеть мозаику из поврежденных блоков начиная от места повреждения. Почти все файлы архивы перестануть распаковываться с места повреждения и до конца. Тоесть им
скорее всего смерть. Тестовые файлы - откроются но будем видеть "мусор" в месте повреждения.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы