From owner-freebsd-current@FreeBSD.ORG Mon Sep 16 11:16:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6355188B; Mon, 16 Sep 2013 11:16:18 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04.sare.net (proxypop04.sare.net [194.30.0.65]) by mx1.freebsd.org (Postfix) with ESMTP id 232B323CA; Mon, 16 Sep 2013 11:16:17 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id 8735E9DCEC7; Mon, 16 Sep 2013 13:06:17 +0200 (CEST) Subject: Re: ZFS secondarycache on SSD problem on r255173 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Borja Marcos X-Priority: 3 In-Reply-To: Date: Mon, 16 Sep 2013 13:06:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es> References: <1379069539.824504225.3b9xwugp@fmst-6.ukr.net> To: Steven Hartland X-Mailer: Apple Mail (2.1283) Cc: "Justin T. Gibbs" , freebsd-current@freebsd.org, Dmitryy Makarov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Mon, 16 Sep 2013 11:16:18 -0000 On Sep 13, 2013, at 2:18 PM, Steven Hartland wrote: > This is a recent bit of code by Justin cc'ed, so he's likely the best = person to > investigate this one. Hmm. There is still a lot of confusion surrounding all this, and it's a = time bomb waiting to explode. A friend had serious problems on 9.2 with the gnop trick in order to = force a 4 KB block size. After a reboot, ZFS would insist on trying to find the .nop device for the ZIL which, of = course, did no longer exist. In his case, for some reason, ZFS didn't identify the labelled gpt/name or gptpd/uuid devices as = valid, and the pool wouldn't attach. Curiously, it did identify the = L2ARC=20 without problems. The cure was to disable GPT labels using loader.conf (I don't remember = if he disabled kern.geom.label.gptid.enable, kern.geom.label.gpt.enable = or both) in order to force it to use the "classical" daXpY nomenclature. As I said, this sounds like a time bomb in the works. There seems to be = some confusion in the ZFS between the different naming schemes you can use for a disk partition right now ( daXpY, gpt label or gptid). Borja.