Ещё раз, не путайте "побилось" и " корректные, но не актуальные/консистентные данные". Для каждой из этих проблем есть свой способ пэрещения. Если мы про "побилось", то это Решается чек суммами - Т.е. При записи генерируется чексумма путем расчёта хеша и записывается рядом/вместе с данными. При чтении этих данные считается хеш блока и сверяется с тем, которой у нас был посчитан. Если совпадает - все ок, отдаем блок. Если нет, то кидаем ошибку и помечаем блок потерянным/сбойным, читаем со второй копии, ребилдим. Таким образом, мы обеспечили защиту от silent corrupt. Т.к. Не все данные мы часто читаем, то для минимизации риска, что побьется обе копии, то делается дополнительный scrubbing, то пересчет/проверка  контрольных сумм в фоне всех данных на кластере. Так работает большинство нормальных систем хранения (включая распределенные).

спасибо
тогда возвращаемся к исходному вопросу: какие из систем "нормальные"?
ceph - "да"
seaweed - скорее "нет"
кто ещё "да"?

Ну я могу сказать, что все Enterprise схд работают так. Плюс тот же VMware vSAN из HCI/SDS. За остальных не скажу

"побившийся результат" будет обнаружен bluestore checksum. Не вижу никаких проблем (если у вас size > 2)

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

А seaweed почему нет? Архитектурно скорее да

Ну или если да, речь о том, что запись сначала пройдет нормально, а потом тихо испортится со временем, то потом ошибка обнаружится чексуммой

scrubbing о котором Николай написал выше, там недавно появился в wishlist
https://github.com/chrislusf/seaweedfs/issues/1519

Атомарность обеспечивается в ЛЮБОЙ хоть более-менее нормальной СХД, просто потому, что запись всегда строго синхронна и ответ в гостевую ОС (ACK) идет только ПОСЛЕ того, как получено подтверждение о том, что данные успешно записаны на все копии/устройства/контроллеры/etc. журналирование для атомарности вообще-то не особо нужно. И более того, запись может побиться всегда независимо от того есть журнал или нет. Вопрос только в том, как это будет отбработано и чем

Это не атомарность. Атомарность - это то, что запись либо применится целиком, либо не применится вообще

Ситуация: идет запись 1 мб блока. Рубится посередине питание

512 кб записалось, а 512 кб нет

yep.Либо у вас запись прошла (успешно всегда и везде) или не прошла. Состояние «частично прошла» невозможна для потребителя.

ACK в ОС не пойдет пока не запишем 1MB. Поэтому гость будет считать, что блок не записан. И СХД тоже

у меня наверное ещё паранойя человека из embedded: контроллер может сказать ack, а на носитель запишутся нули вместо данных
в энтерпрайзе это возможно редкость, а вот в девайсах с питанием от батареек - норма жизни

Ага. А физически 512 кб УЖЕ ЗАПИСАЛОСЬ

Причем потенциально это могли быть разные 512 кб на разных репликах

Не ну это трешъъъъ

Пофиг. Это внутренние проблемы схд, которые почистят эти 512к мусора в фоне. ОС через дефолтный таймаут сделает retry и снова попробует записать исходный  1MB и будет ждать пока не получит ACK.

Не пофиг, т.к. для начала нужно понять, что это мусор