From owner-freebsd-fs@freebsd.org Tue May 17 17:06:44 2016 Return-Path: Delivered-To: freebsd-fs@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 E98EBB3F35A for ; Tue, 17 May 2016 17:06:44 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from smtp.simplesystems.org (smtp.simplesystems.org [65.66.246.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B88661105 for ; Tue, 17 May 2016 17:06:44 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by smtp.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id u4HH6fv9028372; Tue, 17 May 2016 12:06:42 -0500 (CDT) Date: Tue, 17 May 2016 12:06:41 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Ben RUBSON cc: freebsd-fs@freebsd.org Subject: Re: Best practice for high availability ZFS pool In-Reply-To: <40C35566-B7FB-4F59-BB41-D43BC0362C26@gmail.com> Message-ID: References: <5E69742D-D2E0-437F-B4A9-A71508C370F9@FreeBSD.org> <40C35566-B7FB-4F59-BB41-D43BC0362C26@gmail.com> User-Agent: Alpine 2.20 (GSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (smtp.simplesystems.org [65.66.246.90]); Tue, 17 May 2016 12:06:42 -0500 (CDT) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 17:06:45 -0000 On Tue, 17 May 2016, Ben RUBSON wrote: >> On 17 may 2016 at 15:24, Bob Friesenhahn wrote: >> >> There is at least one case of zfs send propagating a problem into the receiving pool. I don't know if it broke the pool. Corrupt data may be sent from one pool to another if it passes checksums. > > Do you have any link to this problem ? Would be interesting to know if it was possible to come-back to a previous snapshot / consistent pool. I don't have a link but I recall that it had something to do with the ability to send file 'holes' in the stream. > I think that making ZFS send/receive has a higher security level than mirroring to a second (or third) JBOD box. > With mirroring you will still have only one ZFS pool. This is a reasonable assumption. > However, if send/receive makes the receiving pool the exact 1:1 copy > of the sending pool, then the thing which made the sending pool to > corrupt could reach (and corrupt) the receiving pool... I don't know > whether or not this could occur, and if ever it occurs, if we have > the chance to revert to a previous snapshot, at least on the > receiving side... Zfs receive does not result in a 1:1 copy. The underlying data organization can be completely different and compression or other options can be changed. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/