For me all this images are RBD v1 images, without layering. # rbd info sas3copies/env4-spool rbd image 'env4-spool': size 10240 MB in 2560 objects order 22 (4096 KB objects) block_name_prefix: rb.0.1536881.238e1f29 format: 1 (the one reported here : Mar 25 21:17:58 murmillia kernel: [ 2205.255938] obj_request ffff88025a2b3c48 Mar 25 21:17:58 murmillia kernel: [ 2205.255940] ->object_name <rb.0.1536881.238e1f29.000000000439> Mar 25 21:17:58 murmillia kernel: [ 2205.255941] ->offset 0 Mar 25 21:17:58 murmillia kernel: [ 2205.255943] ->length 28672 Mar 25 21:17:58 murmillia kernel: [ 2205.255944] ->type 0x1 Mar 25 21:17:58 murmillia kernel: [ 2205.255945] ->flags 0x3 Mar 25 21:17:58 murmillia kernel: [ 2205.255946] ->which 1 Mar 25 21:17:58 murmillia kernel: [ 2205.255948] ->xferred 28672 Mar 25 21:17:58 murmillia kernel: [ 2205.255949] ->result 0 ) At VM level, this block device is formated in ext4, and used for Exim4 (MTA) spool, and can handle a lots of writes. And this ceph pool use 3 replica, with a "per network" CRUSH rule. Le mardi 25 mars 2014 à 15:44 -0500, Alex Elder a écrit : > Olivier, it appears this is a layered image, i.e., the image > is a clone of another. Can you tell us any more about the > way these images are organized? Do you have one master image > and others are based on that? Is there more than one layer to > the organization? (Do these questions make sense?) > > -Alex > -- > 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 > -- 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
