From owner-freebsd-current@freebsd.org Mon Oct 3 17:12:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10A49AF391D for ; Mon, 3 Oct 2016 17:12:44 +0000 (UTC) (envelope-from evansus@gmail.com) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C46BDC1 for ; Mon, 3 Oct 2016 17:12:43 +0000 (UTC) (envelope-from evansus@gmail.com) Received: by mail-yw0-x229.google.com with SMTP id i129so112252889ywb.0 for ; Mon, 03 Oct 2016 10:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:content-transfer-encoding:from:message-id:date:cc:to :mime-version; bh=gEOWNZwrt2lBMx826K9qoHUNYdObWzJDdyODQlM0zG0=; b=VpxGm2FMy4l/2Rdis7CVCrtKscHrtYnnqbgiARJZxJdqRXTcwO5yBuVdxKtsWznIG2 LrqmBU+z9rTVtNR/fJmr24FRcjrPNGvN9W8Wlq4x8j14e8n0dZW/CQuZkeTLd6hz0LD/ Qo4dqJnLoqUzWWOgH7sXkrlfoj5Ng3RUKFC64x04GnXZKkzDNFgAEu2MKjPA0o1S4JYD co9RFTe6hoyug87OgGz/qPHpxx8SdYre+OGYpFXCU/3WwoTUoN6Ukr+ZF0sRJq+HXzzF S9yE/F3mIO/rGxmwv8+VitXGJMamRqijjChAkIFJV5gny+01dfXWBS6HBwkqAjqYXTbY lWoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:content-transfer-encoding:from :message-id:date:cc:to:mime-version; bh=gEOWNZwrt2lBMx826K9qoHUNYdObWzJDdyODQlM0zG0=; b=GSfzI9PrlDFogcThKzG46fWFLw1mTMfAX6yKYiHM5vMu8ks5IXLJwKyPDi0hyS9BzG vsRwcats7xgwb2edqofqK4lPfhp2t2VFkSK6P5mFDJxnSOoCKoFkZg1QgWw0/S76yHW6 4JZPdWQgA3PPhWz4TzzSyLN4roynDk/yYBnaicCMS/4KOzUJqWu0w9Gb1HZITEgvNMw8 CzWP0n2UuaBc/b34Z6DBNRlwwShtSQaEQcHP0e1Q1zMyX54++pa6Z/ZMZNw3LtolxH9x 2tV8yfZNbF14T5DWcDG9EpVnsi1lCo68Tlin3t5StKSfaez+G2ItCoHdVd4NoqoJL+eR oOwA== X-Gm-Message-State: AA6/9Rn7YtBUG5fW31KMrv36XUt8eQqUMbDibT5MTP23kJtBSV8/GfR6pcxzGqnGd6A81A== X-Received: by 10.129.86.131 with SMTP id k125mr15979734ywb.21.1475514762897; Mon, 03 Oct 2016 10:12:42 -0700 (PDT) Received: from [10.0.0.44] ([208.102.167.120]) by smtp.gmail.com with ESMTPSA id i132sm10377281ywc.53.2016.10.03.10.12.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Oct 2016 10:12:42 -0700 (PDT) Subject: Re: ZFS - Abyssal slow on copying Content-Transfer-Encoding: quoted-printable From: Evan Susarret Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (13G34) Message-Id: <93D024AE-408C-4C1D-882D-9C526F2BB276@gmail.com> Date: Mon, 3 Oct 2016 13:12:41 -0400 Cc: freebsd-current@freebsd.org To: ohartman@zedat.fu-berlin.de Mime-Version: 1.0 (1.0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 17:12:44 -0000 In case you are still trying to get this resolved: Since you have enabled deduplication in the past, unfortunately the deduplic= ation tables must be loaded into memory for any and all writes. ZFS must det= ermine if all writes match a previous block, to 1) increment the dedup count= for matches, or 2) decrement the dedup count for a no-longer needed block. This often means that the table must be loaded from disk repeatedly, especia= lly if the table is large enough that it is purged from memory often. It is e= ven possible to get your pool into a state where it cannot be imported due t= o the amount of memory required. =46rom the disk activity and slowness you described, it sounds like the dedu= p table (DDT) is being loaded, dumped, and loaded again repeatedly. I don't know of the top of my head if you can use the 'zdb' command to exami= ne the current DDT table, but there is a way to simulate the effect of enabl= ing dedup on a given dataset using zdb in order to estimate the size of the D= DT table that would result. The only resolution, as Allan stated, is to zfs send and zfs recv the datase= t into a new copy that does not have dedup enabled, or recreate it from scra= tch. Depending if you enabled dedup on single dataset, multiple datasets, or= the whole pool, it may be easiest to recreate the whole pool. This is a sid= e-effect of dedup that some have referred to as 'toxic', and some googling w= ill show that it is a common issue encountered when experimenting with dedup= (on all platforms). Some guides will recommend only enabling dedup if you know that your data wi= ll have many duplicated blocks, and also that the tables will easily fit int= o memory. There are also guides that can help to estimate the amount of ram r= equired to hold a DDT based on the blocksize and number of blocks in the dat= aset. This can be complicated by many factors, so it is usually best to avoi= d turning dedup on unless you are sure that it will help rather than hinder u= sage. Hope this helps! Evan=