Chris Mason wrote on 2016/03/28 10:09 -0400:
On Sat, Mar 26, 2016 at 09:11:53PM +0800, Qu Wenruo wrote:
On 03/25/2016 11:11 PM, Chris Mason wrote:
On Fri, Mar 25, 2016 at 09:59:39AM +0800, Qu Wenruo wrote:
Chris Mason wrote on 2016/03/24 16:58 -0400:
Are you storing the entire hash, or
On Sat, Mar 26, 2016 at 09:11:53PM +0800, Qu Wenruo wrote:
>
>
> On 03/25/2016 11:11 PM, Chris Mason wrote:
> >On Fri, Mar 25, 2016 at 09:59:39AM +0800, Qu Wenruo wrote:
> >>
> >>
> >>Chris Mason wrote on 2016/03/24 16:58 -0400:
> >>>Are you storing the entire hash, or just the parts not
On 03/25/2016 11:11 PM, Chris Mason wrote:
On Fri, Mar 25, 2016 at 09:59:39AM +0800, Qu Wenruo wrote:
Chris Mason wrote on 2016/03/24 16:58 -0400:
Are you storing the entire hash, or just the parts not represented in
the key? I'd like to keep the on-disk part as compact as possible for
On Fri, Mar 25, 2016 at 09:59:39AM +0800, Qu Wenruo wrote:
>
>
> Chris Mason wrote on 2016/03/24 16:58 -0400:
> >Are you storing the entire hash, or just the parts not represented in
> >the key? I'd like to keep the on-disk part as compact as possible for
> >this part.
>
> Currently, it's
Chris Mason wrote on 2016/03/24 16:58 -0400:
On Tue, Mar 22, 2016 at 09:35:35AM +0800, Qu Wenruo wrote:
Introduce a new tree, dedupe tree to record on-disk dedupe hash.
As a persist hash storage instead of in-memeory only implement.
Unlike Liu Bo's implement, in this version we won't do hack
On Tue, Mar 22, 2016 at 09:35:35AM +0800, Qu Wenruo wrote:
> Introduce a new tree, dedupe tree to record on-disk dedupe hash.
> As a persist hash storage instead of in-memeory only implement.
>
> Unlike Liu Bo's implement, in this version we won't do hack for
> bytenr -> hash search, but add a
Introduce a new tree, dedupe tree to record on-disk dedupe hash.
As a persist hash storage instead of in-memeory only implement.
Unlike Liu Bo's implement, in this version we won't do hack for
bytenr -> hash search, but add a new type, DEDUP_BYTENR_ITEM for such
search case, just like in-memory
