On 03/07/2017 04:35 PM, Gregory Farnum wrote: > Creating a snapshot generally involves a round-trip to the monitor, > which requires a new OSDMap epoch (although it can coalesce) ? ie, the > monitor paxos commit and processing the new map on all the OSDs/PGs. > Destroying a snapshot involves adding the snapshot ID to an > interval_set in a new OSDMap epoch; and then going through the snap > trimming process (which can be fairly expensive). > If you send a write to a snapshotted object, it is (for > FileStore-on-xfs) copied on write. (FileStore-on-xfs does > filesystem-level copy-on-write, which is one reason we kept hoping it > would be our stable future...) I think BlueStore also does block-level > copy-on-write. It's a one-time penalty. Concise answer. Makes sense. I'm slowly getting this stuff. My take away? Snapshots are *way* more affordable than creating or deleting pools. But significantly more expensive than just reading and writing objects. So use snapshots for human scale stuff. Big-ish things humans care about, things that happen at time scales humans can participate in. Don't be too cute and clever here. Keep my clever to what I read and write, from and to, zillions of objects. (Playing on the zillions-of-scale is still a kick!) Thanks, -kb
 |