On 01/04/2017 03:41 PM, Brian Andrus wrote: > Think "many objects, few pools". The number of pools do not scale well > because of PG limitations. Keep a small number of pools with the > proper number of PGs. I finally got it through my head, seems the larger answer is: Not only it is okay to have a (properly configured) pool grow to insane numbers of objects, the inverse is also true; keep the number of pools not just small, but to a very bare minimum. For example, Cephfs, which aspires to scale to crazy sizes, only uses two pools. And when Cephfs picks up the ability to offer multiple Cephfs file systems in of a single cluster...it will probably still only be using two pools. Continuing along with my theme of trying to understand Ceph (specifically RADOS, if that matters): Snapshots! What does a snapshot cost? In time? In other resources? When do those costs hit? What does it cost to destroy a snapshot? What does it cost to accumulate multiple snapshots? What does it cost to alter a snapshotted object? (Does that alteration cost hit only once or does it linger?) Whatever their costs, what makes them greater and what makes them smaller? It is sensible to make snapshots programmatically? If so, how rapidly? For example, one idea in the back of my mind is whether there would be a way to use snapshots as a way to kinda fake transactions. I have no idea whether that might be clever or an abuse of the feature... I would love it if someone could toss out some examples of the sorts of things snapshots are good for and the sorts of things they are terrible for. (And some hints as to why, please.) Thanks, -kb
 |