From owner-freebsd-fs@FreeBSD.ORG  Fri Jun 12 16:31:52 2015
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id CFB17EB2
 for <freebsd-fs@hub.freebsd.org>; Fri, 12 Jun 2015 16:31:52 +0000 (UTC)
 (envelope-from ticso@cicely7.cicely.de)
Received: from raven.bwct.de (raven.bwct.de [85.159.14.73])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "raven.bwct.de", Issuer "BWCT" (not verified))
 by mx1.freebsd.org (Postfix) with ESMTPS id 67EE2E00
 for <freebsd-fs@freebsd.org>; Fri, 12 Jun 2015 16:31:51 +0000 (UTC)
 (envelope-from ticso@cicely7.cicely.de)
Received: from mail.cicely.de ([10.1.1.37])
 by raven.bwct.de (8.13.4/8.13.4) with ESMTP id t5CGCcvG055635
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
 for <freebsd-fs@freebsd.org>; Fri, 12 Jun 2015 18:12:39 +0200 (CEST)
 (envelope-from ticso@cicely7.cicely.de)
Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9])
 by mail.cicely.de (8.14.5/8.14.4) with ESMTP id t5CGCaN0079030
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
 Fri, 12 Jun 2015 18:12:36 +0200 (CEST)
 (envelope-from ticso@cicely7.cicely.de)
Received: from cicely7.cicely.de (localhost [127.0.0.1])
 by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id t5CGCahs086780;
 Fri, 12 Jun 2015 18:12:36 +0200 (CEST)
 (envelope-from ticso@cicely7.cicely.de)
Received: (from ticso@localhost)
 by cicely7.cicely.de (8.14.2/8.14.2/Submit) id t5CGCZWI086779;
 Fri, 12 Jun 2015 18:12:35 +0200 (CEST) (envelope-from ticso)
Date: Fri, 12 Jun 2015 18:12:35 +0200
From: Bernd Walter <ticso@cicely7.cicely.de>
To: freebsd-fs@freebsd.org
Cc: Bernd Walter <ticso@cicely7.cicely.de>
Subject: ZFS dedup problem
Message-ID: <20150612161235.GC85104@cicely7.cicely.de>
Reply-To: ticso@cicely.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386
User-Agent: Mutt/1.5.11
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9,
 T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0
X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2015 16:31:52 -0000

On one given system I have some ZFS filesystems with dedup enabled.
Now it happened to me that because of some strange disk problem
a deduped file got damaged because RAIDZ redundance wasn't enough
in this case.
Well, ok so far.
Without dedup I would just ignore snapshots, delete the file in the
current dataset, recopy it from backup source and be done.
With dedup however the new file got relinked to the unreadable data.
Well - I could theoretically disable dedup to recopy the file, but
if I reenable dedup any other file with same content might get
relinked to the bad data as well.
In this case it was Ok for me to drop all snapshots to work around.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.