>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: _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
