On 24/12/2013 05:42, Christian Balzer wrote: > > Hello, > > from what has been written on the roadmap page and here, I assume that the > erasure coding option with Firefly will be (unsurprisingly) a pool option. Hi Christian, You are correct. It is set when a pool of type "erasure" is created for instance : ceph osd pool create poolname 12 12 erasure creates an erasure pool "poolname" with 12 pg and uses the default erasure code plugin ( jerasure ) with parameters K=6, M=2 meaning each object is spread over 6+2 OSDs and you can sustain the loss of two OSDs. It can be changed with ceph osd pool create poolname 12 12 erasure erasure-code-k=2 erasure-code-m=1 which is the equivalent of having 2 replicas using 1.5 times the space instead of 2 times. > > Given the nature of this beast I doubt that it can just be switched on > with a live pool, right? Yes. > > If so, what are the thoughts/plans to allow for a seamless and transparent > migration, other than a "deploy more hardware, create a new pool, migrate > everything by hand (with potential service interruptions)" approach? > One possibility is to use tiering. An erasure code pool is created and set to receive objects demoted from the replica pool when they have not been used in a long time. If the object is accessed from the replica pool, it is first promoted back to it and this is transparent to the user ( modulo the delay of promoting it when accessed again ). Cheers > Regards, > > Christian > -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
