On Mon, May 13, 2013 at 11:35 AM, Harald Rößler <Harald.Roessler@xxxxxx> wrote: > On Mon, 2013-05-13 at 18:55 +0200, Gregory Farnum wrote: >> On Mon, May 13, 2013 at 9:10 AM, Harald Rößler <Harald.Roessler@xxxxxx> wrote: >> > >> > Hi Together >> > >> > is there a description of how a shared image works in detail? Can such >> > an image can be used for a shared file system on two virtual machine >> > (KVM) to mount. In my case, write on one machine and read only on the >> > other KVM.Are the changes are visible on the read only KVM? >> >> The image is just striped across RADOS objects. In general you can >> think of it behaving exactly like a hard drive connected to your >> computer over iSCSI — a proper shared FS (eg, OCFS2) will work on top >> of it, but there's no magic that makes running an ext4 mount on two >> machines work... >> -Greg >> Software Engineer #42 @ http://inktank.com | http://ceph.com > > Hi Greg > > Thanks, and sorry maybe I did not explain clearly what I mean or. When > I' mounting a rbd image on two KVM machines, then if I am writing a file > in one system the other system does not recognize the change of the file > system. I thought there is some magic in librbd which give the OS the > information that something have changed, like when I am mounting a NFS > share. > > I saw in the documentation the "--shared tag" : > > Option for lock add that allows multiple clients to lock the same image > if they use the same tag. The tag is an arbitrary string. This is useful > for situations where an image must be open from more than one client at > once, like during live migration of a virtual machine, or for use > underneath a clustered file system. > > The use case is multiply KVM systems are mounting the same data storage, > without use of cephfs (MDS). Yeah, that absolutely will not work. RBD is a block device, not a shared filesystem. ;) -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
