> Message: 24 > Date: Tue, 24 Jun 2014 09:39:50 -0500 > From: Chad Seys <cws...@physics.wisc.edu> > To: "ceph-users@lists.ceph.com" <ceph-users@lists.ceph.com> > Subject: [ceph-users] limitations of erasure coded pools > Message-ID: <201406240939.50550.cws...@physics.wisc.edu> > Content-Type: Text/Plain; charset="us-ascii" > > Hi All, > Could someone point me to a document (possibly a FAQ :) ) describing the > limitations of erasure coded pools? Hopefully it would contain the when and > how to use them as well.
Hi Chad, this Ceph Enterprise 1.2 FAQ provides a good overview: https://download.inktank.com/docs/ICE%201.2%20-%20Cache%20and%20Erasure%20Coding%20FAQ.pdf > E.g. I read about people using replicated pools as a front end to erasure > coded pools, but I don't know why they're deciding to do this, or how they are > setting this up. Unless you have a very specific use-case then you don't want to interact directly with an EC pool, for a number of reasons - but here's one really good one: objects cannot be modified "in-place", so to speak, the OSDs have to read (at least) k chunks, compute the data, make the write, recompute the updated object's EC. This extra overhead probably makes EC unsuitable for block storage, whereas it might be OK for particularly read-dominated object storage. The replicated cache front-end/tier helps to service random IO bursts (in writeback mode) and keeps hot objects available to serve to clients without recomputing. -- Cheers, ~Blairo _______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
