From owner-freebsd-bugs@FreeBSD.ORG Mon Oct 1 23:40:02 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B89A61065670 for ; Mon, 1 Oct 2012 23:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 894708FC18 for ; Mon, 1 Oct 2012 23:40:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q91Ne28c014861 for ; Mon, 1 Oct 2012 23:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q91Ne2od014860; Mon, 1 Oct 2012 23:40:02 GMT (envelope-from gnats) Resent-Date: Mon, 1 Oct 2012 23:40:02 GMT Resent-Message-Id: <201210012340.q91Ne2od014860@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Steven Hartland Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93BCA106564A for ; Mon, 1 Oct 2012 23:35:50 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 658448FC15 for ; Mon, 1 Oct 2012 23:35:50 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.5/8.14.5) with ESMTP id q91NZnux019643 for ; Mon, 1 Oct 2012 23:35:49 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.5/8.14.5/Submit) id q91NZn8P019620; Mon, 1 Oct 2012 23:35:49 GMT (envelope-from nobody) Message-Id: <201210012335.q91NZn8P019620@red.freebsd.org> Date: Mon, 1 Oct 2012 23:35:49 GMT From: Steven Hartland To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: bin/172259: ZFS fails to receive valid snapshots (patch included) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 23:40:02 -0000 >Number: 172259 >Category: bin >Synopsis: ZFS fails to receive valid snapshots (patch included) >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Oct 01 23:40:02 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Steven Hartland >Release: 8.3-RELEASE >Organization: Multiplay >Environment: FreeBSD dev 8.3-RELEASE-p4 FreeBSD 8.3-RELEASE-p4 #22: Mon Sep 17 17:18:32 UTC 2012 root@dev:/usr/obj/usr/src/sys/MULTIPLAY amd64 >Description: When using zfs receive to restore data saved with zfs send there is the possibility that the receive will fail due to replication of snapshots information being processed in a random order. In addition to this when receiving snapshots where the parent from snapshot is replaced by another needless failures occur which can be seen clearly in verbose mode. >How-To-Repeat: 1. First create some volumes & backups on a test pool (testtank) zfs create testtank/test zfs create testtank/test/1 zfs create testtank/test/2 zfs snapshot -r testtank@backup zfs send -R testtank@backup > recvtest-1 zfs rename -r testtank@backup testtank@backup-last zfs snapshot -r testtank@backup zfs send -R -i testtank@backup-last testtank@backup > recvtest-2 zfs destroy -r testtank@backup-last zfs rename -r testtank@backup testtank@backup-last zfs snapshot -r testtank@backup zfs send -R -i testtank@backup-last testtank@backup > recvtest-3 2. Clean out the pool zfs destroy -r testtank 3. Restore the backups in order zfs recv -duFv testtank < recvtest-1 zfs recv -duFv testtank < recvtest-2 zfs recv -duFv testtank < recvtest-3 At some point usually the third receive it will error and leave the filesystems in a random state. You'll see temporary named filesystems e.g. zfs list -t all testtank/recv-16556-1 testtank/recv-16556-1/1 testtank/recv-16556-1/2 >Fix: The first problem is down to the fact that the replication of snapshots are processed in a random order resulting in snapshot deletes and renames happening in the wrong order. The second problem is caused by deletes / renames effecting the parent snapshot of existing filesystems. The current process needlessly attempts to rename child filesystems of the deleted parents. The attached patch fixes both issues. The first by ensuring the list of snapshots used is sorted The second by maintaining a list of deleted guid's which are used to check against before performing a parent guid based rename. >Release-Note: >Audit-Trail: >Unformatted: