Re: Why is dedup inline, not delayed (as opposed to offline)? Explain like I'm five pls.

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

Al wrote on 2016/01/20 14:43 +0000:
> Duncan <1i5t5.duncan <at> cox.net> writes:
>
>>
>> Al posted on Sat, 16 Jan 2016 12:27:16 +0000 as excerpted:
>>
>
> That it does, Duncan, thank you!
>
> I was suggesting, albeit implicitly, that unless you're really short of
> block dev space (!), which is a pretty naff dedup strategy, dedup isn't time
> critical AFAIC(See). My server memory is not huge and I'd happily let it
> chug away dedup'ing than have the whole thing run like a dog for lack of memory.
>
> I'm looking forward to using it; keep up the very good work.
>

The design of providing two backends is for different use case.

If you don't thinkg inmemory is good, then just use ondisk.
Even inmemory doesn't seems useful for you, there is still some cases 
that you doesn't know.

The design of inmemory is not to save your block dev space, but to limit 
the overhead of write to a consist value.

If one day you just want to write 64K data, but you need to randomly 
read 128K metadata and found a hash miss, and do the real write, then 
you may understand the meaning of inmemory backend.



To conclude, something meaningless to you doesn't mean it's meaningless 
for everyone.
If you really think the design is naff, I'm very glad if you can provide 
a better one.

Thanks,
Qu

>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>