From owner-freebsd-geom@FreeBSD.ORG Mon Jun 30 22:23:30 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C42DD1065673 for ; Mon, 30 Jun 2008 22:23:30 +0000 (UTC) (envelope-from hywel@hmallett.co.uk) Received: from lisbon.directrouter.com (lisbon.directrouter.com [72.249.30.130]) by mx1.freebsd.org (Postfix) with ESMTP id 9DFD58FC16 for ; Mon, 30 Jun 2008 22:23:30 +0000 (UTC) (envelope-from hywel@hmallett.co.uk) Received: from hmallett.plus.com ([81.174.158.104] helo=[192.168.0.66]) by lisbon.directrouter.com with esmtpa (Exim 4.69) (envelope-from ) id 1KDRmQ-0001Ni-46; Mon, 30 Jun 2008 17:23:26 -0500 Message-Id: <27A404FA-FDEE-4A8E-A16D-DCBC9E41AED0@hmallett.co.uk> From: Hywel Mallett To: Ivan Voras In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 30 Jun 2008 23:23:24 +0100 References: <0A8C1986-1DC1-4445-9111-0DEDBBCC6847@hmallett.co.uk> <20080622233638.4hclgmsw8408s4cg@www.hmallett.co.uk> X-Mailer: Apple Mail (2.924) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - lisbon.directrouter.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hmallett.co.uk X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-geom@freebsd.org Subject: Re: Filesystem replication geom proposal X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2008 22:23:30 -0000 On 29 Jun 2008, at 21:48, Ivan Voras wrote: > > Yes, gmirror would have to grow support for "smart" resilvering, > probably by having a bitmap of changed blocks maintained on the > working drive(s) so it can only update the changed data instead of > whole drives (which would happen now if ggated would support > automatic reconnects). > The problem with that simplistic approach is that because write-order fidelity is not maintained, during the resynchronisation the slave/ secondary is inconsistent.