Sorry, I was mixing concepts. I was thinking of RBD snapshots, which require the file system to be consistent before creating. I have been exploring an idea for creating remote, asynchronous copies of RBD images, hopefully with some form of delayed state updating. I've been reviewing the features of DRBD and LVM to see if these components might add features to make this feasible. The RBD image replication features within a pool do work well and clearly maintain a consistent state for the contained file systems. I use them daily. :) ~jpr On 11/21/2013 12:52 PM, Gregory Farnum wrote: > On Thu, Nov 21, 2013 at 10:13 AM, John-Paul Robinson <jpr@xxxxxxx> wrote: >> Is this statement accurate? >> >> As I understand DRBD, you can replicate online block devices reliably, >> but with Ceph the replication for RBD images requires that the file >> system be offline. > It's not clear to me what replication you're asking about with Ceph > here. Ceph is internally replicating the block device to keep it > available in case of server failures, and that's all happening online. > If you want a logically distinct copy (? this seems to be what Dimitri > is referring to with adding a 3rd DRBD copy on another node) then that > model is a lot different than in the classical storage world — it > might be that you're saying "I want 3-copy durability instead of > 2-copy" which you can do online (for all images stored in a given > pool); or you might be after a copy you can use as a stable backup > point, which you can do by taking a snapshot of the image (but here > you probably want to quiesce the filesystem, yes); or you might be > after something completely different which I'm not thinking of... > -Greg > Software Engineer #42 @ http://inktank.com | http://ceph.com _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |