From owner-freebsd-fs@FreeBSD.ORG Wed Dec 23 17:16:01 2009 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 55E571065692 for ; Wed, 23 Dec 2009 17:16:01 +0000 (UTC) (envelope-from chreo@chreo.net) Received: from kontorsmtp2.one.com (kontorsmtp2.one.com [195.47.247.17]) by mx1.freebsd.org (Postfix) with ESMTP id 1E5498FC14 for ; Wed, 23 Dec 2009 17:16:00 +0000 (UTC) Received: from [10.0.0.12] (h-250-220.A218.priv.bahnhof.se [85.24.250.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kontorsmtp2.one.com (Postfix) with ESMTP id A215026C0043B for ; Wed, 23 Dec 2009 17:00:06 +0000 (UTC) Message-ID: <4B324C95.5060601@chreo.net> Date: Wed, 23 Dec 2009 18:00:05 +0100 From: Chreo User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Zpool on GELI halts during import 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: Wed, 23 Dec 2009 17:16:01 -0000 Hi there, I've a raidz zpool on 6 1,5TB vdevs running on GELI GEOMs. It has been performing fine until a few days ago when all of a sudden it started to fail being imported. This is on 8-stable zpool import reports: zpool import pool: Ocean id: 18338821095971722517 state: ONLINE status: One or more devices contains corrupted data. action: The pool can be imported using its name or numeric identifier. see: http://www.sun.com/msg/ZFS-8000-4J config: Ocean ONLINE raidz1 ONLINE label/Disk_1.eli ONLINE label/Disk_2.eli ONLINE label/Disk_3.eli ONLINE label/Disk_4.eli UNAVAIL corrupted data label/Disk_5.eli UNAVAIL corrupted data label/Disk_6.eli ONLINE but doing the actual import simply cause the process to halt it's progress (at least a ktrace does not reveal any activity). I've also tried doing the import using: zpool import -f -o failmode=continue Ocean with the same result. Right, so my first thought was that this has been caused by the notorious uberblock issue (where the . Unfortunately doing zdb -uuv -e Ocean also stops responding (no disk activity noted after 1s of running the command). zdb -l /dev/label/Disk_X.eli Reports identical data for all 6 drives (they only differ in the GUID as expected). Now running on 7-stable instead (the system was upgraded a monthe ago) does not change the behaviour fundamentally, import still stops responding, however zdb -e Ocean now cause a segfault so it's not much of an "improvment". Any ideas as to how I could get this into a importable state or find out what went backwards? Cheers Christian Elmerot