From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:42004 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751367AbcATOtx (ORCPT ); Wed, 20 Jan 2016 09:49:53 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aLu51-0002u5-HK for linux-btrfs@vger.kernel.org; Wed, 20 Jan 2016 15:49:51 +0100 Received: from 87-127-115-15.static.enta.net ([87.127.115.15]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jan 2016 15:49:51 +0100 Received: from 6401e46d by 87-127-115-15.static.enta.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jan 2016 15:49:51 +0100 To: linux-btrfs@vger.kernel.org From: Al <6401e46d@opayq.com> Subject: Re: Why is dedup inline, not delayed (as opposed to offline)? Explain like I'm five pls. Date: Wed, 20 Jan 2016 14:49:45 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-btrfs-owner@vger.kernel.org List-ID: Rich Freeman thefreemanclan.net> writes: > I think he is actually suggesting a hybrid approach where a bit of > effort is done during operations to greatly streamline out-of-line > deduplication. I'm not sure how close we are to that already, or if > any room for improvement remains. > > -- Hopefully, we can tweak the split between in-memory and on blkdev. I don't see myself needing in-memory much (cc'd email with attachments perhaps?).