From owner-freebsd-current@FreeBSD.ORG Mon Sep 16 21:17:58 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 B08EA161 for ; Mon, 16 Sep 2013 21:17:58 +0000 (UTC) (envelope-from gibbs@freebsd.org) Received: from aslan.scsiguy.com (aslan.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 890DB2F18 for ; Mon, 16 Sep 2013 21:17:58 +0000 (UTC) Received: from [192.168.6.145] (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.7/8.14.5) with ESMTP id r8GLHn2C023694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Sep 2013 15:17:50 -0600 (MDT) (envelope-from gibbs@freebsd.org) Subject: Re: ZFS secondarycache on SSD problem on r255173 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=utf-8 From: "Justin T. Gibbs" X-Priority: 3 In-Reply-To: <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> Date: Mon, 16 Sep 2013 15:17:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> References: <1379069539.824504225.3b9xwugp@fmst-6.ukr.net><74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es><1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (aslan.scsiguy.com [70.89.174.89]); Mon, 16 Sep 2013 15:17:51 -0600 (MDT) Cc: freebsd-current@freebsd.org, Borja Marcos , Dmitriy 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 21:17:58 -0000 Sorry for being slow to chime in on this thread. I live in Boulder, CO = and we've had a bit of rain. :-) As Steven pointed out, the warning is benign, but does show that the = code I committed to -current is not optimizing the allocation size for = L2ARC devices. The fix for this is to find the best place during pool = creation/load/import to call vdev_ashift_optimize() on L2ARC devices. I = will look into this tomorrow, but feel free to suggest a good spot if = you look at it before I can. -- Justin On Sep 16, 2013, at 6:43 AM, Steven Hartland = wrote: > Thats correct the new code knows the what the ashift of the underlying = disk should > be so if it detects a vdev with a lower ashift you get this warning. >=20 > I suspect the issue is that cache devices don't have an ashift, so = when the check > is done it gets a default value and hence the warning. >=20 > I'd have to did some more to see how ashift in cache devices is or = isn't implemented. >=20 > Regards > Steve >=20 > ----- Original Message ----- From: "Dmitriy Makarov" = > To: "Steven Hartland" > Cc: "Borja Marcos" ; ; = "Justin T. Gibbs" > Sent: Monday, September 16, 2013 1:29 PM > Subject: Re[3]: ZFS secondarycache on SSD problem on r255173 >=20 >=20 >> And have to say that ashift of a main pool doesn't matter. >> I've tried to create pool with ashift 9 (default value) and with = ashift 12 with creating gnops over gpart devices, export pool, destroy = gnops, import pool. There is the same problem with cache device. >>=20 >> There is no problem with ZIL devices, they reports ashift: 12 >>=20 >> children[1]: >> type: 'disk' >> id: 1 >> guid: 6986664094649753344 >> path: '/dev/gpt/zil1' >> phys_path: '/dev/gpt/zil1' >> whole_disk: 1 >> metaslab_array: 67 >> metaslab_shift: 25 >> ashift: 12 >> asize: 4290248704 >> is_log: 1 >> create_txg: 22517 >>=20 >> Problem with cache devices only, but in zdb output tere is nothing at = all about them. >>=20 >> --- =D0=98=D1=81=D1=85=D0=BE=D0=B4=D0=BD=D0=BE=D0=B5 = =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 --- =D0=9E=D1=82 = =D0=BA=D0=BE=D0=B3=D0=BE: "Steven Hartland" < killing@multiplay.co.uk > >> =D0=94=D0=B0=D1=82=D0=B0: 16 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80= =D1=8F 2013, 14:18:31 >>=20 >> Cant say I've ever had a issue with gnop, but I haven't used it for >> some time. >>=20 >> 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. >>=20 >> 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 >>=20 >> Regards >> Steve >> ----- Original Message ----- From: "Borja Marcos" < >>=20 >> --- =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9 =D0=9C=D0=B0=D0=BA=D0=B0= =D1=80=D0=BE=D0=B2 >>=20 >>=20 >> --- =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9 =D0=9C=D0=B0=D0=BA=D0=B0= =D1=80=D0=BE=D0=B2 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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.=20 > 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. >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"