Thanks. Another reason is the checksum in the attr of object used for deep scrub in EC pools should be computed when modify the object. When supporting the random write, We should caculate the whole object for checksum, even if there is a bit modified. If only supporting append write, We can get the checksum based on the previously checksum and the append date which is more quickly.
Am I right? 2014-10-21 0:36 GMT+08:00 Gregory Farnum <g...@inktank.com>: > This is a common constraint in many erasure coding storage system. It > arises because random writes turn into a read-modify-write cycle (in order > to redo the parity calculations). So we simply disallow them in EC pools, > which works fine for the target use cases right now. > -Greg > > > On Monday, October 20, 2014, 池信泽 <xmdx...@gmail.com> wrote: > >> hi, cephers: >> >> When I look into the ceph source code, I found the erasure code >> pool not support >> the random write, it only support the append write. Why? Is that random >> write of is erasure code high cost and the performance of the deep scrub is >> very poor? >> >> Thanks. >> > > > -- > Software Engineer #42 @ http://inktank.com | http://ceph.com >
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
