From nobody@FreeBSD.org  Thu Jun  5 07:45:43 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 7A1EC10656C0
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  5 Jun 2008 07:45:43 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 69E238FC16
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  5 Jun 2008 07:45:43 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m557jhHO087176
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 5 Jun 2008 07:45:43 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m557jg5Z087175;
	Thu, 5 Jun 2008 07:45:42 GMT
	(envelope-from nobody)
Message-Id: <200806050745.m557jg5Z087175@www.freebsd.org>
Date: Thu, 5 Jun 2008 07:45:42 GMT
From: Denis Barov <dindin@dindin.ru>
To: freebsd-gnats-submit@FreeBSD.org
Subject: gmirror have inappropriate logic when working with bad hard-drive
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         124294
>Category:       kern
>Synopsis:       [geom] gmirror(8) have inappropriate logic when working with bad hard-drive
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-geom
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jun 05 07:50:00 UTC 2008
>Closed-Date:    Sun Feb 07 03:15:49 UTC 2010
>Last-Modified:  Sun Feb 07 03:15:49 UTC 2010
>Originator:     Denis Barov
>Release:        FreeBSD 6,7,8
>Organization:
Yandex
>Environment:
FreeBSD sepulca.yandex.ru 6.3-STABLE FreeBSD 6.3-STABLE #5: Wed Feb 27 12:26:30 MSK 2008     root@sepulca.yandex.ru:/usr/obj/usr/RELENG_6/src/sys/SEPULCA  amd64
>Description:
For example, we have two gmirrored hard drives (da0 and da1). If first
drive partially dead (have hardware errors) then,  during system boot,
gmirror will insert it, and then try boot from it. In better case, boot
fails. In worse case system will boot up and gmirror will try to sync
second good disk with first bad. In this case data will be lost on both
drives. I think it's serious trouble, because there's no way to get
failover with any amount of disks. 
>How-To-Repeat:
Use gmirror with bad hard drive.
>Fix:
none

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-geom 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Jun 5 10:48:35 UTC 2008 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=124294 

From: Ulf Lilleengen <lulf@stud.ntnu.no>
To: bug-followup@FreeBSD.org, dindin@dindin.ru
Cc:  
Subject: Re: kern/124294: [geom] gmirror(8) have inappropriate logic when
	working with bad hard-drive
Date: Tue, 17 Jun 2008 18:30:29 +0200

 When presented two drives with equal or different content, gmirror have no
 way to know which drive is good.  As far as gmirror is concerned, as long as
 the metadata is ok, the content should be as well. To avoid this, one could
 use ZFS or geli to verify the integrity of the data.
 
 However, perhaps one way to avoid this would be to prevent gmirror to sync
 from a disk which is has booted from. However, even if the boot succeeds and the good
 disk is not synced with corrupted data, there is no guarantee that other
 parts of the disk that you booted from is good, so you might be assuming you
 have a good disk, but you're really booting from a bad one.
 
 Any suggestions?
 
 -- 
 Ulf Lilleengen
State-Changed-From-To: open->feedback 
State-Changed-By: pjd 
State-Changed-When: wto 11 sie 2009 13:48:32 UTC 
State-Changed-Why:  
Could you verify you have sysctl kern.geom.mirror.disconnect_on_failure 
set to 1? It should disconnect component that behaves badly on first I/O 
error. After disconnect, another (valid) component will have more fresh 
metadata and should be choosen as master when synchronization is needed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=124294 
State-Changed-From-To: feedback->closed 
State-Changed-By: linimon 
State-Changed-When: Sun Feb 7 03:14:37 UTC 2010 
State-Changed-Why:  
Feedback timeout (> 1 year.) 

To submitter: if this is still a problem, please let us know and we 
can re-open the ticket. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=124294 
>Unformatted:
