From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.iobjects.de ([188.40.134.68]:59288 "EHLO mail02.iobjects.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751783AbcLIQIA (ORCPT ); Fri, 9 Dec 2016 11:08:00 -0500 Subject: Re: duperemove : some real world figures on BTRFS deduplication To: Chris Murphy , =?UTF-8?Q?Sw=c3=a2mi_Petaramesh?= References: <81bcff57-4bee-18d5-cac4-3359150730a5@petaramesh.org> <2d4f5ee2-fc2b-ac48-8f4b-eecf8936b9e1@petaramesh.org> Cc: Btrfs BTRFS From: =?UTF-8?Q?Holger_Hoffst=c3=a4tte?= Message-ID: <584AD6DE.3080500@applied-asynchrony.com> Date: Fri, 9 Dec 2016 17:07:58 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 12/09/16 16:43, Chris Murphy wrote: >> If compression has nothing to do with this, then this is heavy >> fragmentation. > > It's probably not that fragmented. Due to compression, metadata > describes 128KiB extents even though the data is actually contiguous. > > And it might be the same thing in my case also, even though no > compression is involved. In that case you can quickly collapse physically contiguous ranges by reflink-mv'ing (ie. a recent mv) the file across subvolume boundaries and back. :) -h