From owner-freebsd-fs@FreeBSD.ORG Fri Sep 16 03:07:47 2011 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 5EB24106564A for ; Fri, 16 Sep 2011 03:07:47 +0000 (UTC) (envelope-from olgeni@FreeBSD.org) Received: from mail.colby.tv (93-62-141-58.ip22.fastwebnet.it [93.62.141.58]) by mx1.freebsd.org (Postfix) with ESMTP id DC8168FC14 for ; Fri, 16 Sep 2011 03:07:46 +0000 (UTC) Received: from server.colby.local (localhost [127.0.0.1]) by server.colby.local (8.14.4/8.14.4) with ESMTP id p8G2SmfH046369; Fri, 16 Sep 2011 04:28:48 +0200 (CEST) (envelope-from olgeni@FreeBSD.org) Received: from exchange.colby.local ([192.168.1.11] helo=exchange.colby.local) with IPv4:25 by server.colby.local; 16 Sep 2011 04:28:48 +0200 Received: from [10.1.0.3] ([10.1.0.3]) by exchange.colby.local over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Sep 2011 04:28:48 +0200 Date: Fri, 16 Sep 2011 04:28:47 +0200 (CEST) From: Jimmy Olgeni X-X-Sender: olgeni@olgeni.olgeni To: Artem Belevich In-Reply-To: Message-ID: References: <201109152044.p8FKiYDV030137@freefall.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-OriginalArrivalTime: 16 Sep 2011 02:28:48.0209 (UTC) FILETIME=[5D68D410:01CC7418] Cc: freebsd-fs@FreeBSD.org Subject: Re: bin/148296: [zfs] [loader] [patch] Very slow probe in /usr/src/sys/boot/zfs/zfs.c 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: Fri, 16 Sep 2011 03:07:47 -0000 On Thu, 15 Sep 2011, Artem Belevich wrote: > Any idea what fixed it? > > Actually, I'm not sure it's actually got fixed. At least I don't see > anything obvious in SVN history for sys/boot/zfs/zfs.c since ZVSv28 > commit. I've got gptzfsboot built about 4-6 weeks back and at that > time it was as slow as it ever was probing drives in an 8-drive raidz > pool. For me it was happening when booting off a mirror, but I haven't seen this happen in a while. Last time I saw this was definitely in the pre-ZFSv28 times. It could be that the problem is still there but I am unable to see it due to different caching on the disks, as I swapped hardware a few times since then. Also, the attached patch did not handle "holes" in the GPT partition sequence so it was kind of dangerous if you had a less than linear setup :) -- jimmy