From owner-freebsd-fs@FreeBSD.ORG Mon Jun 7 11:43:37 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0C4E106566B for ; Mon, 7 Jun 2010 11:43:37 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 10DDF8FC0C for ; Mon, 7 Jun 2010 11:43:36 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA23524; Mon, 07 Jun 2010 14:43:33 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C0CDB64.6090304@icyb.net.ua> Date: Mon, 07 Jun 2010 14:43:32 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Jeremy Chadwick References: <4C0CAABA.2010506@icyb.net.ua> <20100607083428.GA48419@icarus.home.lan> <4C0CB3FC.8070001@icyb.net.ua> <20100607090850.GA49166@icarus.home.lan> <4C0CBBCA.3050304@icyb.net.ua> <20100607103829.GA50106@icarus.home.lan> In-Reply-To: <20100607103829.GA50106@icarus.home.lan> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: zfs i/o error, no driver error X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 11:43:37 -0000 on 07/06/2010 13:38 Jeremy Chadwick said the following: > My understanding is that a "vdev I/O error" indicates some sort of > communication failure with a member in the pool, or some other layer > within FreeBSD (GEOM I think, like you said). I don't think there has > to be a 1:1 ratio between vdev I/O errors and controller/disk errors. > > For AHCI and storage controllers, I/O errors are messages that are > returned from the controller to the OS, or from the disk through the > controller to the OS. I suppose it's possible ZFS could be throwing > an error for something that isn't actually block/disk-level. > > I'm interested to see what this turns out to be! Yes, me too :) I skimmed through the sources and so far I see at least two possibilities: 1) Decompression error for a filesystem with compression. Again, I don't know why that could happen if there are no checksum errors or hardware errors. 2) Successful but short read from disk. Same thing - I don't know why that could happen. And I am sure that there are other possibilities too. -- Andriy Gapon