Supposedly, on 2013-Apr-22, at 01.10 PDT(-0700), someone claiming to be Loic Dachary scribed:
> Hi Christopher,
>
> You wrote "A modified client/library could be used to store objects that should be sharded, vs "standard" ceph treatment. In this model, each shard would be written to a seperate PG, and each PG would we stored on exactly one OSD. " but there is no way for a client to enforce the fact that two objects are stored in separate PG.
Poorly worded. The idea is that each shard becomes a seperate object, and the encoder/sharder would use CRUSH to identify the OSDs to hold the shards. However, the OSDs would treat the shard as an n=1 replication and just store locally.
Actually, looking at this this morning, this is actually harder than the prefered alternative (i.e. grafting a encode/decode into the (e)OSD. It was meant to cover the alternative approaches. I didn't like this one, but it now appears to be more difficult, and non-deterministic of the placement.
One question on CRUSH (it's been too long since I read the paper), if x is the same for two objects, and, using an n=3 returns R={OSD18,OSD45,OSD97}, if an object is handed to OSD45 that matches x, but has an n=1, would OSD45 store it, or would it forward it to OSD18 to store? If it would this idea is DOA. Also, if x is held invariant, but n changes, does the same R set get returned (truncated to n members)?
Thx
Christopher
>
> Am I missing something ?
>
> On 04/22/2013 09:23 AM, Christopher LILJENSTOLPE wrote:
>> Supposedly, on 2013-Apr-18, at 14.31 PDT(-0700), someone claiming to be Plaetinck, Dieter scribed:
>>
>>> On Thu, 18 Apr 2013 16:09:52 -0500
>>> Mark Nelson <mark.nelson@xxxxxxxxxxx> wrote:
>>
>>>>
>>>
>>> @Bryan: I did come across cleversafe. all the articles around it seemed promising,
>>> but unfortunately it seems everything related to the cleversafe open source project
>>> somehow vanished from the internet. (e.g. http://www.cleversafe.org/) quite weird...
>>>
>>> @Sage: interesting. I thought it would be more relatively simple if one assumes
>>> the restriction of immutable files. I'm not familiar with those ceph specifics you're mentioning.
>>> When building an erasure codes-based system, maybe there's ways to reuse existing ceph
>>> code and/or allow some integration with replication based objects, without aiming for full integration or
>>> full support of the rados api, based on some tradeoffs.
>>>
>>> @Josh, that sounds like an interesting approach. Too bad that page doesn't contain any information yet :)
>>
>> Greetings - it does now - see what you all think…
>>
>> Christopher
>>
>>>
>>> Dieter
>>
>>
>> --
>> 李柯睿
>> Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc
>> Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf
>> Check my calendar availability: https://tungle.me/cdl
>
> --
> Loïc Dachary, Artisan Logiciel Libre
--
李柯睿
Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc
Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf
Check my calendar availability: https://tungle.me/cdlAttachment:
signature.asc
Description: OpenPGP digital signature
