From mboxrd@z Thu Jan 1 00:00:00 1970 From: Loic Dachary Subject: Re: Erasure code properties in OSDMap Date: Wed, 12 Mar 2014 14:10:25 +0100 Message-ID: <53205CC1.20401@dachary.org> References: <531C5AD5.9060109@cloudwatt.com> <531F17B0.4080506@cloudwatt.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1QUmVI9GKjobdHknOp75XhCRFPRMWf5Vb" Return-path: Received: from smtp.dmail.dachary.org ([91.121.254.229]:40875 "EHLO smtp.dmail.dachary.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752983AbaCLNK3 (ORCPT ); Wed, 12 Mar 2014 09:10:29 -0400 In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: John Spray Cc: Ceph Development This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1QUmVI9GKjobdHknOp75XhCRFPRMWf5Vb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/03/2014 13:39, John Spray wrote: > I am sure all of that will work, but it doesn't explain why these > properties must be stored and named separately to crush rulesets. To > flesh this out one also needs "get" and "list" operations for the sets > of properties, which feels like overkill if there is an existing place > we could be storing these things. The reason I'm taking such an > interest in what may seem something minor is that once this has been > added, we will be stuck with it for some time once external tools > start depending on the interface. > > The ruleset-based approach doesn't have to be more complicated for CLI > users, we would essentially replace any "myproperties" above with a > ruleset name instead. > > osd pool create mypool > osd set ruleset-properties =3D [=3D...] > > The simple default cases of "pool create mypool > erasure" could be handled by making sure there exist default rulesets > called "erasure" and "replicated" rather than having these be magic > words to the commands that cause ruleset creation. Rulesets currently > just have numbers instead of names, but it would be simpler to add > names to rulesets than to introduce a whole new type of object to the > interface. Here are the default parameters OPTION(osd_pool_default_erasure_code_properties, OPT_STR, "erasure-code-plugin=3Djerasure " "erasure-code-technique=3Dreed_sol_van " "erasure-code-k=3D4 " "erasure-code-m=3D2 " ) // default properties of osd pool create The k and m parameters have a clear relationship with the pool size. And = they also define the minimum number of items the crush ruleset must be ab= le to provide. The other parameters relate to the code/decode functions a= nd are better understood in the context of the OSD than crush. This is th= e reason why I don't see these properties as being exclusively linked to = the crush ruleset or the OSD. By introducing a new set of properties asso= ciated to the erasure code feature there is no need to chose. Does that make sense ? > > John > > On Tue, Mar 11, 2014 at 2:03 PM, Loic Dachary > wrote: >> On 11/03/2014 13:21, John Spray wrote: >>> From a high level view, what is the logical difference between the >>> crush ruleset and the properties object? I'm thinking about how this= >>> is exposed to users and tools, and it seems like both would be define= d >>> as "the settings about data placement and encoding". I certainly >>> understand the separation internally, I am just concerned about makin= g >>> the interface we expose upwards more complicated by adding a new type= >>> of object. >>> >>> Is there really a need for a new type of properties object, instead o= f >>> storing these properties under the existing ruleset ID? >> These properties are used to configure the new feature that was introd= uced in Firefly : erasure coded pools. From a user point of view the simp= lest would be to >> >> ceph osd pool create mypool erasure >> >> and rely on the fact that a default ruleset will be created using the = default erasure code plugin with the default parameters. >> >> If the sysadmin wants to tweak the K+M factors (s)he could: >> >> ceph osd set properties myproperties k=3D10 m=3D4 >> >> and then >> >> ceph osd pool create mypool erasure myproperties >> >> which would implicitly ask the default erasure code plugin to create a= ruleset named "mypool-ruleset" after configuring it with myproperties. >> >> If the sysadmin wants to share rulesets between pools instead of relyi= ng on their implicit creation, (s)he could >> >> ceph osd create-serasure myruleset myproperties >> >> and then ceph osd set crush_ruleset as per usual. And if (s)he really = wants fine tuning, manually adding the ruleset is also possible. >> >> I feel confortable explaining this but I'm probably much too familiar = with the subject to be a good judge of what makes sense to someone new or= not ;-) >> >> Cheers >> >>> John >>> >>> >>> On Sun, Mar 9, 2014 at 12:13 PM, Loic Dachary >>> wrote: >>>> Hi Sage & Sam, >>>> >>>> I quickly sketched the replacement of the pg_pool_t::properties map = with a OSDMap::properties list of maps at https://github.com/dachary/ceph= /commit/fe3819a62eb139fc3f0fa4282b4d22aecd8cd398 and explained how I see = it at http://tracker.ceph.com/issues/7662#note-2 >>>> >>>> It indeed makes things simpler, more consistent and easier to explai= n. I can provide an implementation this week if this seems reasonable to = you. >>>> >>>> Cheers >>>> >>>> -- >>>> Lo=C4=8Fc Dachary, Senior Developer >>>> >>>> -- >>>> 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, Senior Developer >> --=20 Lo=C3=AFc Dachary, Artisan Logiciel Libre --1QUmVI9GKjobdHknOp75XhCRFPRMWf5Vb 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.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMgXMEACgkQ8dLMyEl6F21kTQCdG7LMJ6vfnLpqOkFm6sbnFr5P qwwAn1j6s25PFHGiekx/HF04i0hwPedX =U98q -----END PGP SIGNATURE----- --1QUmVI9GKjobdHknOp75XhCRFPRMWf5Vb--