From owner-freebsd-fs@FreeBSD.ORG Tue Nov 2 18:28:05 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81338106564A for ; Tue, 2 Nov 2010 18:28:05 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 31BDA8FC18 for ; Tue, 2 Nov 2010 18:28:04 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PDLaV-0004EJ-Kh for freebsd-fs@freebsd.org; Tue, 02 Nov 2010 19:28:03 +0100 Received: from firewall.andxor.it ([195.223.2.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Nov 2010 19:28:03 +0100 Received: from lapo by firewall.andxor.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Nov 2010 19:28:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Lapo Luchini Date: Tue, 02 Nov 2010 19:27:51 +0100 Lines: 29 Message-ID: <4CD05827.9040903@lapo.it> References: <49BAD057.6060602@jrv.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: firewall.andxor.it User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101102 SeaMonkey/2.0.10 In-Reply-To: <49BAD057.6060602@jrv.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=C8F252FB Cc: Luigi Lauro Subject: Re: ZFS recv doesn't properly skip existing snapshots X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 18:28:05 -0000 James R. Van Artsdalen wrote: > I'm working on a way to keep a remote pool in sync with a local pool > using zfs send/recv. [...] > It appears "zfs recv" is supposed to simply skip any snapshot it already > has [...] But instead "zfs recv" appears to never get in > sync with the input stream again and simple exits. I have come to the same conclusions, it seems to me that it follows a "fail fast" approach and simply closes after the first "ignore", even though the could be useful data afterwards. In this thread http://opensolaris.org/jive/thread.jspa?threadID=116790 they're asking the O.P. "why are you sending the wrong initial snap?" which applies to the case of sending a single filesystem, but as you correctly pointed out when sending "zfs send -RI" an inconsistent state can be reached even using the "correct" inizial snapshot, which might exist on some of the sub-filesystems and not on the others. I wonder if it might be as simple as removing the "fail fast" exit code which I thin might be used after the "already exists; ignoring" warning, but I still have to find the place in the code that is printed. Oh, on 8-STABLE it is printed in line 1885 of /usr/src/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c and the is no "fail fast" at all, so I guess it is failing (without verbose errors) in recv_skip(). -- Lapo Luchini - http://lapo.it/