From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 11 15:59:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B9DB4258 for ; Thu, 11 Jul 2013 15:59:06 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4B71741 for ; Thu, 11 Jul 2013 15:59:06 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id hr11so6773769vcb.20 for ; Thu, 11 Jul 2013 08:59:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=SqVPF4dc5Jwr7mo0azieQVCu5ZhQ/ZWhqLBq0yZ0dV0=; b=NzfAHReMie4pZVu5oXsJYWATM/anPcENPup0qf6a9bGA58SM5dgHVd9ciSxQFiJXAi /Cw4bS8pYcpTXwlex3N/HDRYtyZxKdVxZ6GDj1nTZtCM03XCLBZ2nl70fgD48mYS+txO PG7BY106MihbxQzFcPzS+rQK1sWEDsRggAHlaSS95vYDbrS3YRttiSf0YJf9qjwO8aWM e6woiiAtKPisQjgr3aVK22Dp7TKD5qZfOwMSVOOlu03TmRH/NxpwQY37N81wROsxIpTu 4X3AkvPTRVLE9ZlvqDRxLhL2s1ftYHmjyjDj2v5oTdj2bZZX1WT5bTUCiOJ/6G8X+ttk k/NQ== MIME-Version: 1.0 X-Received: by 10.221.64.18 with SMTP id xg18mr22250420vcb.57.1373558345703; Thu, 11 Jul 2013 08:59:05 -0700 (PDT) Received: by 10.58.226.66 with HTTP; Thu, 11 Jul 2013 08:59:05 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Jul 2013 09:59:05 -0600 Message-ID: Subject: Re: Attempting to roll back zfs transactions on a disk to recover a destroyed ZFS filesystem From: Will Andrews To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnLLlZx8sC6MACTxN9OLfFah1rt9UpvAKkWEGyGd/7HAAilf7QR83A6zZENCQDPbYY6pYKF X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:59:06 -0000 On Thu, Jul 11, 2013 at 9:04 AM, Alan Somers wrote: > "zpool export" does not wipe the transaction history. It does, > however, write new labels and some metadata, so there is a very slight > chance that it might overwrite some of the blocks that you're trying > to recover. But it's probably safe. An alternative, much more > complicated, solution would be to have ZFS open the device > non-exclusively. This patch will do that. Caveat programmer: I > haven't tested this patch in isolation. This change is quite a bit more than necessary, and probably wouldn't apply to FreeBSD given the other changes in the code. Really, to make non-exclusive opens you just have to change the g_access() calls in vdev_geom.c so the third argument is always 0. However, see below. > On Thu, Jul 11, 2013 at 8:43 AM, Reid Linnemann wrote: >> But now we are to my current problem. When attempting to roll back with >> this script, it tries to dd zero'd bytes to offsets into the disk device >> (/dev/ada1p3 in my case) where the uberblocks are located. But even >> with kern.geom.debugflags >> set to 0x10 (and I am runnign this as root) I get 'Operation not permitted' >> when the script tries to zero out the unwanted transactions. I'm fairly >> certain this is because the geom is in use by the ZFS subsystem, as it is >> still recognized as a part of the original pool. I'm hesitant to zfs export >> the pool, as I don't know if that wipes the transaction history on the >> pool. Does anyone have any ideas? You do not have a choice. Changing the on-disk state does not mean the in-core state will update to match, and the pool could get into a really bad state if you try to modify the transactions on disk while it's online, since it may write additional transactions (which rely on state you're about to destroy), before you export. Also, rolling back transactions in this manner assumes that the original blocks (that were COW'd) are still in their original state. If you're using TRIM or have a pretty full pool, the odds are not in your favor. It's a roll of the dice, in any case. --Will.