Date: Mon, 16 Sep 2013 13:06:14 +0200 From: Borja Marcos <borjam@sarenet.es> To: Steven Hartland <killing@multiplay.co.uk> Cc: "Justin T. Gibbs" <gibbs@FreeBSD.org>, freebsd-current@freebsd.org, Dmitryy Makarov <supportme@ukr.net> Subject: Re: ZFS secondarycache on SSD problem on r255173 Message-ID: <74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es> In-Reply-To: <EAD621124C1549208BD93D20657E1BD0@multiplay.co.uk> References: <1379069539.824504225.3b9xwugp@fmst-6.ukr.net> <EAD621124C1549208BD93D20657E1BD0@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?74C1D072-77BB-4D6C-B78F-C8D2731FA0CF>