From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tartarus.angband.pl ([89.206.35.136]:41662 "EHLO tartarus.angband.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751190AbdH1Kc0 (ORCPT ); Mon, 28 Aug 2017 06:32:26 -0400 Date: Mon, 28 Aug 2017 12:32:22 +0200 From: Adam Borowski To: shally verma Cc: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org Subject: Re: status of inline deduplication in btrfs Message-ID: <20170828103222.bvdsjpzloo4yubzb@angband.pl> References: <7e12fa55-d01a-6c02-f798-2b63cf3b4a6d@jp.fujitsu.com> <20170826161524.xz5xylimnqfucdte@angband.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 In-Reply-To: Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Mon, Aug 28, 2017 at 12:49:10PM +0530, shally verma wrote: > Am bit confused over here, is your description based on offline-dedupe > here Or its with inline deduplication? It doesn't matter _how_ you get to excessive reflinking, the resulting slowdown is the same. By the way, you can try "bees", it does nearline-dedupe which is for practical purposes as good as fully online, and unlike the latter, has no way to damage your data in case of bugs (mistaken userland dedupe can at most make the kernel pointlessly read and compare data). I haven't tried it myself, but what it does is dedupe using FILE_EXTENT_SAME asynchronously right after a write gets put into the page cache, which in most cases is quick enough to avoid writeout. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄⠀⠀⠀⠀