From owner-freebsd-current@FreeBSD.ORG Fri Nov 13 01:27:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F0E8106566C; Fri, 13 Nov 2009 01:27:04 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id EB4128FC0A; Fri, 13 Nov 2009 01:27:03 +0000 (UTC) Received: by pwj15 with SMTP id 15so1873518pwj.3 for ; Thu, 12 Nov 2009 17:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7BJZAVO8VE2F9u3NLNTioMpmeUWFlAT5ZbDXB2Qt/V0=; b=hlEhMU3Q7gL0GdYFnNZXl5Y/osWVg117D5gds/w2FNMzk1dKS3DDBu2bHIHV97oV7v /MzZdowTpLFHY3hYRbjoDTGfS1442KtBM8n6m4/X6gsv732Dg2EtvCwtSiyzoCo6afhR G6KlHRgEHsG2xBxk4ce4BUkIQ90M4w3zXmnZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CW7n4dWMzsK/gcSTDAG2nh1SSSvokNLBBGOcahNm0e2Ft7ytFHSJ19XlYOu8M4krEf yQsQ2oCfM7/J1A1hG8Kgqugtfg9KGhSDE2u0u2aXUdfogQu0RKMfcwluwDsQtVN9c2md nf/8aURqL4MWiae30Tq1tnlcFUF0TdjBwMoMw= MIME-Version: 1.0 Received: by 10.143.138.7 with SMTP id q7mr420029wfn.314.1258073698747; Thu, 12 Nov 2009 16:54:58 -0800 (PST) In-Reply-To: <4AD710D6.70404@buchlovice.org> References: <4AD710D6.70404@buchlovice.org> Date: Thu, 12 Nov 2009 16:54:58 -0800 Message-ID: From: Matt Reimer To: =?ISO-8859-2?Q?Radek_Val=E1=B9ek?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, rnoland@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 01:27:04 -0000 2009/10/15 Radek Val=C3=A1=C5=A1ek : > Hi, > > I want to ask if there is something new in adding support to > gptzfsboot/zfsboot for reading gang-blocks? > > From Sun's docs: > > Gang blocks > > When there is not enough contiguous space to write a complete block, the = ZIO > pipeline will break the I/O up into smaller 'gang blocks' which can later= be > assembled transparently to appear as complete blocks. > > Everything works fine for me, until I rewrite kernel/world after system > upgrade to latest one (releng_8). After this am I no longer able to boot > from zfs raidz1 pool with following messages: > >>/ ZFS: i/o error - all block copies unavailable > />/ ZFS: can't read MOS > />/ ZFS: unexpected object set type lld > />/ ZFS: unexpected object set type lld > />/ > />/ FreeBSD/i386 boot > />/ Default: z:/boot/kernel/kernel > />/ boot: > />/ ZFS: unexpected object set type lld > />/ > />/ FreeBSD/i386 boot > />/ Default: tank:/boot/kernel/kernel > />/ boot: Radek, Try the attached patch (sponsored by VPOP Technologies). I found an overflow in /sys/cddl/boot/zfs/zfssubr.c:vdev_raidz_read() that was causing my 6x1TB raidz2 array to fail to boot. Apply the patch, build everything in /sys/boot, and then make sure you update both gptzfsboot and /boot/loader. Robert, I'm guessing you couldn't replicate this because your array was small enough not to result in block numbers overflowing an int. The kernel source for the corresponding functionality is in /sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_raidz.c:vdev_raidz_map= _alloc(). There all these variables are uint64_t, but I think unnecessarily. I tried changing the boot loader's vdev_raidz_read() variables to all uint64_t but then gptzfsboot would reboot itself, likely due to a stack overflow. The attached patch just changes a few variables that, after a quick analysis, seemed likely to overflow. If this looks good, would someone commit it? Matt