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 [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
