А вот упоминали тут про silent corrupted. Это получается... когда

данные "по тихому" ломаются как то? Именно по этому же получается FR должен быть 3, что бы была какая то базовая-базовая копия, по которой можно понять что с данными произошли какие то не корректные изменения?

Нет, там контрольные суммы, по ним и понятно, данные корраптнулись или нет

Ну а тогда... все еще не понимаю что такое silent corrupt и почему FR2 - это плохо

silent corruption - это, как пел покойный Свин, "пуля пролетела, в грудь попала мне" Только вместо пули - альфа-частиц

Т.е. данные просто тухнут от времени?) Могут повредится при длительном времени хранения?)

Да

И это фиксится путем создания большого количества копий (например 3). Но на сколько помню из доки, там PG выбирается основной OSD и 2 дополнительных. Ну так и если данные стухли на основном OSD, как PG поймет что они действительно стухли? Что именно просигналит PG, мол "копия битая, давай другую". Те самые контрольные суммы?

Отвечает Александр Друзь: However, there are several drawbacks to having a replication factor of 2: Single Point of Failure: With RF2, if two replicas of a piece of data happen to be on two nodes that fail simultaneously, your data will be unavailable. This is especially problematic if the failures are correlated, such as a rack failure that affects both nodes. Data Durability: If one of your two replicas is corrupted or lost, you're left with a single good copy. Another failure before recovery completes could lead to data loss. Recovery Performance: When a node fails and then returns to health, Ceph will re-replicate data to restore the desired replication level. With RF2, you're recovering from a single surviving copy, which can strain the storage and network resources of the node holding that copy. Less Forgiving of Mistakes: Operations like OSD (Object Storage Daemon) removal or disk replacements need careful planning and monitoring. With RF2, you have less room for error. Mistakenly taking down two nodes that have the replicas of some objects could cause data loss. Capacity Overhead: While RF2 uses less raw storage than RF3 (another common replication factor), it doesn’t provide as much fault tolerance. This means you're making a trade-off between raw storage efficiency and data durability. Writes Require More Coordination: When writing data with RF2, Ceph needs to coordinate the write between two OSDs. While this is also true for RF3 or higher, the trade-off in terms of durability makes higher replication factors more justifiable. Split Brain Scenarios: In scenarios where network partitions occur or if there's a failure in the cluster's quorum mechanism, having just two replicas can lead to a split-brain situation where both copies might get written to independently. Resolving these scenarios can be complex and might lead to data loss or corruption. Given these drawbacks, many organizations opt for a replication factor of 3 (RF3) for critical data. This ensures that even if one node fails, there are still two other copies available, significantly reducing the risk of data loss. If storage costs are a concern, erasure coding could also be considered as an alternative to pure replication in some use cases. It provides a good balance between data durability and storage efficiency, but with its own sets of trade-offs.

Ну да Контрольная сумма не сойдется

ух ля