Date: Mon, 16 Sep 2013 15:17:44 -0600 From: "Justin T. Gibbs" <gibbs@freebsd.org> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-current@freebsd.org, Borja Marcos <borjam@sarenet.es>, Dmitriy Makarov <supportme@ukr.net> Subject: Re: ZFS secondarycache on SSD problem on r255173 Message-ID: <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> In-Reply-To: <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> References: <1379069539.824504225.3b9xwugp@fmst-6.ukr.net><EAD621124C1549208BD93D20657E1BD0@multiplay.co.uk><74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es><DEF92E3685F3411D9B605ACFBEA16D94@multiplay.co.uk><1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <killing@multiplay.co.uk> = 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" = <supportme@ukr.net> > To: "Steven Hartland" <killing@multiplay.co.uk> > Cc: "Borja Marcos" <borjam@sarenet.es>; <freebsd-current@freebsd.org>; = "Justin T. Gibbs" <gibbs@freebsd.org> > 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 <pool> >>=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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?02549AD9-C456-4E17-927C-B4BCC97F8CC8>