>Резвирование репликацией не лучший вариант. Всегда возможна ситуация когда выходят из строя или не доступны все реплики (сразу или по очереди - при этом последная полная реплика умирает до момента полного востановления первой). Это не считая того что 2 стораджа по 10P (сторадж стоящий в Ornl.gov) стоят очень дорого что бы так легко раскидываться местом.

Вы это гуглу расскажите. 5 стораджей по 10P на дешевых компонентах будут стоить на порядок дешевле, чем 2 по 10P на северных. А надежность будут обеспечивать при этом не меньшую.

Картинка вот очень наглядная:
http://blog.backblaze.com/wp-content/uploads/2009/08/cost-of...
вот из этой статьи:
http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-h.../

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

>Разберитесь в архитектуре FS, а покачто спрячьте свои пальцы - а то ведь отломают. для локальных FS - это называется журналом. в Ceph в приведенном фрагменте это называет "recent pgA log entries".

Вопросы были риторические. Вы утверждаете, словно это проблема:
>если допустить что оба osd на которых находится реплика окажутся в down (тривиальный network flap) - будут проблемы. Так как обмена "логом изменения" с клиента на osd - не предусмотрена дизайном.

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

Если пойти по ссылкам из топика, то можно наткнуться на такой комментарий:
http://lwn.net/Articles/379689/ - вот человек, понимает фишку Ceph