From owner-freebsd-questions@freebsd.org Fri Jul 21 00:03:49 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 421E1CFF274 for ; Fri, 21 Jul 2017 00:03:49 +0000 (UTC) (envelope-from frank2@fjl.co.uk) Received: from bs1.fjl.org.uk (bs1.fjl.org.uk [84.45.41.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "bs1.fjl.org.uk", Issuer "bs1.fjl.org.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9822E81A95 for ; Fri, 21 Jul 2017 00:03:48 +0000 (UTC) (envelope-from frank2@fjl.co.uk) Received: from [192.168.1.35] (host86-191-18-76.range86-191.btcentralplus.com [86.191.18.76]) (authenticated bits=0) by bs1.fjl.org.uk (8.14.4/8.14.4) with ESMTP id v6L03k0K071513 for ; Fri, 21 Jul 2017 01:03:46 +0100 (BST) (envelope-from frank2@fjl.co.uk) Subject: Re: zfs send -R | zfs recv aborted To: freebsd-questions@freebsd.org References: <2dbcb271-be11-6ca0-fbf0-f21a21725875@razorfever.net> <64602a81-132a-2f8b-076b-3497acb569e3@fjl.co.uk> <03dbb8de-2d75-6719-1976-8fd02e82ab9d@razorfever.net> From: Frank Leonhardt Message-ID: <82dbfae3-4ae0-0ab6-7268-a7bfb2282083@fjl.co.uk> Date: Fri, 21 Jul 2017 01:03:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <03dbb8de-2d75-6719-1976-8fd02e82ab9d@razorfever.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 00:03:49 -0000 On 19/07/2017 11:21, Derek (freebsd lists) wrote: > On 17-07-18 05:19 PM, Frank Leonhardt wrote: >> >> I'm not 100% sure that datasets that appear to be good on a failed >> send will be safe; I presume you've checked! >> >> So your problem is that you need to free up broken dataset snapshots >> on the receiver. I don't understand why this is a problem - why not >> just "destroy" them? >> > > And here, you've gotten to the heart of the matter. Perhaps the > questions I mean to be asking are: > > - How can I tell which datasets/snapshots were received in-tact, and > which are only partial transfers? (I *presume* some are in-tact, and > they superficially appear to be so.) > - Can this be done using only properties/metadata of the zfs dataset + > pool? (like a receive completed flag) > I can't come up with an answer that would convince me if I was faced with this. But I think there's a reasonable chance that a scrub would pick up any problems. If any block was out of place it would flag as soon as it was read as it would fail the checksum, and scrub reads every block - so if the snapshot shows up, all the blocks below it must be linked and are either there or the branch is broken. > >> I've a dim idea that zxfer might be of some help here, but as you >> say, the OpenZFS from 10.3 onwards has exactly the option you need. >> > > That's a good point. I'll look there for some inspiration - and see > how deep it goes. > >> Am I right in thinking these two machines are colocated? Why not just >> export the pool on one and import on the other? (Lack of drive bays >> being one obvious reason - just get a load of USB->SATA cables and a >> hub). Just a thought. >> > > The source machine is active in service. Okay, so desperate then. Crazy thoughts I'd have when desperate.... Are these in a SAS expander/enclosure? Could you mount the new drives on the old box rather than using the network? How much has changed in the snapshots that you want take with you to the new system (zfs list -t snapshot)? Roll back the new zpool and then do a differential send to the latest snapshot. This might be fairly painless if the original snapshot contains the bulk of the data anyway. And now for completely crazy.... Could you mirror the existing vdevs on to the new disks 1:1 - resilver, take a snapshot and then detach from the mirror and you have a perfect copy? This couldn't possibly work, of course, but I can't actually think why not at 1am... Regards, Frank.