Re: Erasure code properties in OSDMap

[Loic Dachary <loic.dachary@cloudwatt.com>]

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 defined
> as "the settings about data placement and encoding".  I certainly
> understand the separation internally, I am just concerned about making
> 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 of
> storing these properties under the existing ruleset ID?
These properties are used to configure the new feature that was introduced in Firefly : erasure coded pools. From a user point of view the simplest 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=10 m=4

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 relying 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
> <loic.dachary@cloudwatt.com> 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 explain. I can provide an implementation this week if this seems reasonable to you.
>>
>> Cheers
>>
>> --
>> Loďc 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ïc 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