From owner-freebsd-geom@FreeBSD.ORG  Fri May 11 11:08:56 2012
Return-Path: <owner-freebsd-geom@FreeBSD.ORG>
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 54732106566C;
	Fri, 11 May 2012 11:08:56 +0000 (UTC)
	(envelope-from kpielorz_lst@tdx.co.uk)
Received: from mail.tdx.com (mail.tdx.com [62.13.128.18])
	by mx1.freebsd.org (Postfix) with ESMTP id E12928FC08;
	Fri, 11 May 2012 11:08:55 +0000 (UTC)
Received: from OctaHexa64-MkII (HPQuadro64.dmpriest.net.uk [62.13.130.30])
	(authenticated bits=0)
	by mail.tdx.com (8.14.3/8.14.3) with ESMTP id q4BB8mPG034147
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO);
	Fri, 11 May 2012 12:08:49 +0100 (BST)
Date: Fri, 11 May 2012 12:08:53 +0100
From: Karl Pielorz <kpielorz_lst@tdx.co.uk>
To: Alexander Motin <mav@FreeBSD.org>, freebsd-geom@FreeBSD.org
Message-ID: <61CDA17B687F1C733EE1B017@OctaHexa64-MkII>
In-Reply-To: <4FABDE10.8090304@FreeBSD.org>
References: <4FABDE10.8090304@FreeBSD.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: 
Subject: Re: FreeBSD 9-R amd64 - graid, should it survive 'pulling' a disk?
X-BeenThere: freebsd-geom@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: GEOM-specific discussions and implementations
	<freebsd-geom.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
	<mailto:freebsd-geom-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-geom>
List-Post: <mailto:freebsd-geom@freebsd.org>
List-Help: <mailto:freebsd-geom-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-geom>,
	<mailto:freebsd-geom-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 11 May 2012 11:08:56 -0000



--On 10 May 2012 18:26 +0300 Alexander Motin <mav@FreeBSD.org> wrote:

> Hi.
>
> This panic is not in graid code, but it can be called a problem of the
> graid's RAID1 implementation. If some disk returns _write_ failure, that
> failure may now be reported to higher levels. Problem is that UFS SU code
> panics on these errors in some cases. I'll try to look on it nearest time.

Hi,

So for clarity - what you're saying is if one of the servers drops a disk 
from it's graid RAID1 array (for whatever reason) while writing, the error 
could 'bubble up' and have the UFS code panic, because of it? (even though 
the write would have completed on the other drive)?

Is the same true for reads?

-Karl