From owner-freebsd-current@FreeBSD.ORG Mon Sep 16 11:18:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D8A90B85; Mon, 16 Sep 2013 11:18:38 +0000 (UTC) (envelope-from prvs=1971ec67ec=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53F57240B; Mon, 16 Sep 2013 11:18:37 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005982020.msg; Mon, 16 Sep 2013 12:18:28 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 16 Sep 2013 12:18:28 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1971ec67ec=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Borja Marcos" References: <1379069539.824504225.3b9xwugp@fmst-6.ukr.net> <74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es> Subject: Re: ZFS secondarycache on SSD problem on r255173 Date: Mon, 16 Sep 2013 12:18:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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:18:38 -0000 Cant say I've ever had a issue with gnop, but I haven't used it for some time. I did have a quick look over the weekend at your issue and it looks to me like warning for the cache is a false positive, as the vdev for cache doesn't report an ashift in zdb so could well be falling back to a default value. I couldn't reproduce the issue for log here, it just seems to work for me, can you confirm what ashift is reported for your devices using: zdb Regards Steve ----- Original Message ----- From: "Borja Marcos" To: "Steven Hartland" Cc: "Dmitryy Makarov" ; ; "Justin T. Gibbs" Sent: Monday, September 16, 2013 12:06 PM Subject: Re: ZFS secondarycache on SSD problem on r255173 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 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. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.