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
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
