On 17 December 2014 at 04:50, Robert LeBlanc <robert@xxxxxxxxxxxxx> wrote: > There are really only two ways to do snapshots that I know of and they have > trade-offs: > > COW into the snapshot (like VMware, Ceph, etc): > > When a write is committed, the changes are committed to a diff file and the > base file is left untouched. This only has a single write penalty, This is when you are accessing the snapshot image? I suspect I'm probably looking at this differently - when I take a snapshot I never access it "live", I only ever restore it - would that be merging it back into the base? > > COW into the base image (like most Enterprise disk systems with snapshots > for backups): > > When a write is committed, the system reads the blocks to be changed out of > the base disk and places those original blocks into a diff file, then writes > the new blocks directly into the base image. The pros to this approach is > that snapshots can be deleted quickly and the data is "merged" already. Read > access for the current data is always fast as it only has to search one > location. The cons are that each write is really a read and two writes, > recovering data from a snapshot can be slow as the reads have to search one > or more snapshots. Whereabout does qcow2 fall on this spectrum? Thanks, -- Lindsay _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |