From owner-freebsd-stable@FreeBSD.ORG Wed Jan 4 20:14:45 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B69C410656DA for ; Wed, 4 Jan 2012 20:14:45 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id 13ADF8FC0C for ; Wed, 4 Jan 2012 20:14:44 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.5/8.14.5) with ESMTP id q04JhIQK005826 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Jan 2012 21:43:18 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.5/8.14.5/Submit) id q04JhDuR005825 for stable@freebsd.org; Wed, 4 Jan 2012 21:43:13 +0200 (SAST) (envelope-from lordcow) Date: Wed, 4 Jan 2012 21:43:13 +0200 From: Gareth de Vaux To: stable@freebsd.org Message-ID: <20120104194313.GA2558@lordcow.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lordcow.org Cc: Subject: gmirror not synced X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:14:45 -0000 Hi all, I've noticed that the md5 hashes of a couple of files on a gmirror change when I recalculate the hashes. The output usually cycles between 2 hashes per file. I'm guessing this is because each calculation reads the file randomly from 1 of 2 component drives, and the files in question had a few bit flips during their original sync. I also assume this's something you have to live with for gmirror? Is removing and completely rebuilding the secondary drive the only thing you can do (which might fix these bit flips but incur others elsewhere)?