From mboxrd@z Thu Jan 1 00:00:00 1970 From: Loic Dachary Subject: Re: Fwd: Fwd: Reduce read latency and bandwidth for ec pool Date: Tue, 17 Mar 2015 09:39:06 +0100 Message-ID: <5507E82A.9010306@dachary.org> References: <5507DC67.2030800@dachary.org> <5507DF9E.5050903@dachary.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FHBU08Es0qwUrVixvK8KdEfoEqtRCgrWQ" Return-path: Received: from mail2.dachary.org ([91.121.57.175]:59361 "EHLO smtp.dmail.dachary.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752081AbbCQIjI (ORCPT ); Tue, 17 Mar 2015 04:39:08 -0400 In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Xinze Chi Cc: Ceph Development This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FHBU08Es0qwUrVixvK8KdEfoEqtRCgrWQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/03/2015 09:05, Xinze Chi wrote: > RBD. Did you measure that RBD does a significant amount of reads that would be= optimized in this way ? > Maybe we could use tier pool. >=20 > Thanks >=20 > 2015-03-17 16:02 GMT+08:00 Loic Dachary : >> >> >> On 17/03/2015 08:52, Xinze Chi wrote: >>> ---------- Forwarded message ---------- >>> From: Xinze Chi >>> Date: 2015-03-17 15:52 GMT+08:00 >>> Subject: Re: Fwd: Reduce read latency and bandwidth for ec pool >>> To: Loic Dachary >>> >>> >>> Yes, In my VDI environment, client read 4k every time. If we can read= >>> object from only shard. It would reduce the latency and bandwidth a >>> lot. >> >> I'm curious about your workload. Are you using RadosGW ? RBD ? >> >>> Thanks. >>> >>> 2015-03-17 15:48 GMT+08:00 Loic Dachary : >>>> Hi, >>>> >>>> On 17/03/2015 08:27, Xinze Chi wrote: >>>>> hi, loic: >>>>> >>>>> I have an idea which could reduce read latency and bandwidth for= ec pool. >>>>> >>>>> But, I don't know whether it is feasible. >>>>> >>>>> Such as ec pool stripe_width =3D 16384 =3D 4 * 4096, K =3D 4, M= =3D2 >>>>> >>>>> So ceph will partition the total of 16384 bytes to 4 data chunk,= >>>>> and encoding 2 parity chunk >>>>> >>>>> shard_0 include 0 - (4096-1) in original data; >>>>> shard_1 include 4096 - (4096*2 - 1) in original data; >>>>> shard_2 include 4096*2 - (4096 * 3 -1) in original data; >>>>> shard_3 include 4096*3 - (4096 * 4 - 1) in original data >>>>> shard_4 include parity chunk >>>>> shard_5 include parity chunk >>>>> >>>>> Now if client read (offset 0, len 4096) from object, it should >>>>> read 4 shard (from 0-3) and decode all this 4 chunk. >>>>> >>>>> But, this example, maybe we can compute the destination shard >>>>> based on ec pool config ,read offset and read len , we only read >>>>> >>>>> shard_0 and return it to client, because shard_0 has include all da= ta >>>>> as client need. >>>> >>>> That optimization makes sense to me. I guess you're interested in ha= ving small objects in the pool and only read a few bytes at a time ? >>>> >>>> Cheers >>>> >>>>> >>>>> Wait for your comment. >>>>> >>>>> Thanks. >>>>> >>>> >>>> -- >>>> Lo=C3=AFc Dachary, Artisan Logiciel Libre >>>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe ceph-devel"= in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> -- >> Lo=C3=AFc Dachary, Artisan Logiciel Libre >> --=20 Lo=C3=AFc Dachary, Artisan Logiciel Libre --FHBU08Es0qwUrVixvK8KdEfoEqtRCgrWQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlUH6CoACgkQ8dLMyEl6F20GUgCeNxHOmLXeG/yhRa4AnjwXdw0s vbMAn171/pJ0kLAYnkgEPlPCfO8sPBAE =Jw4h -----END PGP SIGNATURE----- --FHBU08Es0qwUrVixvK8KdEfoEqtRCgrWQ--