Re: Question about writeback performance and content address obejct for deduplication

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I created a public repository in oder to show you the concept of step
1 (a simple redirection).
https://github.com/myoungwon/ceph/commit/47f3567a0d5894e9272bf3bcabc95eb71f736a81

Can you give me commets whether this is right way or not?

And i have a question.
Does a simple rediection need struct object_manifest_t?
I think a simple rediection does not need struct object_manifest_t
because promote_object() and start_flush() can be reused.

Thanks.






2017-04-18 22:23 GMT+09:00 Sage Weil <sweil@xxxxxxxxxx>:
> On Tue, 18 Apr 2017, myoungwon oh wrote:
>> Hi sage
>>
>> I am refactoring the source code in order to support the extensible
>> tier (support redirect, dedup, external system)
>>
>> I have a few question.
>>
>> 1. My understanding is that base pool contains all metadata for all
>> objects (do not evicted), and dedup pool or external systems contain
>> the object data.
>> Therefore, The big difference between the cache tier and the
>> extensible tier is whether  base pool contains metadata (such as
>> object_info_t ) or not. Am i wrong?
>
> Yeah.  The base pool effectively becomes and index for everything.
>
>> 2. Do you think the extensible tier should belong to cache_mode_t (in
>> maybe_handle_cache_detail()) ? or is it better to work independently
>> from cache tier.
>
> It should be independent of the cache tiering.  We should probably use the
> tier_of and tiers fields in pg_pool_t but not cache_mode.
>
>> 3. Regarding promotion object and flushing work, I think start_copy() (in
>> promote_object()) and start_fush() can be reused in a simple
>> redirection case ("the object is in that other pool"), if we modify
>> the object (only metadata) is not evicted (removed). Is this right
>> way?
>
> Yes!
>
> I suggest focusing on step 1 being the simple redirection tiering case (no
> dedup) since it'll be tricky enough getting that part right.
>
> Thanks!
> sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux