Эмуляция сбоев ФС. Ломаем PostgreSQL

[outlingo]

У вас "немного странные" представления о работе ФС, потому как сценарий "При попытке записи буфера в файл, вставляется заполненный нулями буфер такого же размера" является невозможным.

[slonpts]

Видимо, вы разбираетесь в теме? Можете написать, какие сценарии бывают, какие являются наиболее вероятными, а какие менее?

[outlingo]

Есть несколько сценариев базовых интересных:

При записи произошла ошибка но часть данных записалась а часть нет (усложненный кейс - вторая половина данных записалась а первая нет)

При сбросе буферов (при синке) произошла ошибка и часть кэша синкнулась а часть нет (усложненный случай - данные записанные позже чиркнули б а записанные раньше нет, бросив ошибку синка)

Ошибки чтения неинтересны

[snpgg]

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

[myxo]

Вообще возможен. Бывают ситуации когда контроллер диска багнутый или просто начинает врать что сделал fsync, хотя данные не записались (а потом машина рестартует и все теряется). Ну и конечно диск может побиться и возвращать любой мусор.

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

[outlingo]

Эти кейсы относятся уже к другой категории, не к реакциям на ошибки, а по сути к методам восстановления данных. Если говорить про БД, то, например, у того же Oracle его redo logs (аналог PG WAL) можно писать в несколько мест параллельно, как раз чтобы нивелировать такие риски

[efi]

А прикольная статья, мне понравилась. Люблю всякие такие эксперименты, попробую поиграться дома. Спасибо!