ZFS secondarycache on SSD problem on r255173

[Justin T. Gibbs]

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 at 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.
> 
> 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.
> 
> I'd have to did some more to see how ashift in cache devices is or isn't implemented.
> 
>   Regards
>   Steve
> 
> ----- Original Message ----- From: "Dmitriy Makarov" <supportme at ukr.net>
> To: "Steven Hartland" <killing at multiplay.co.uk>
> Cc: "Borja Marcos" <borjam at sarenet.es>; <freebsd-current at freebsd.org>; "Justin T. Gibbs" <gibbs at freebsd.org>
> Sent: Monday, September 16, 2013 1:29 PM
> Subject: Re[3]: ZFS secondarycache on SSD problem on r255173
> 
> 
>> 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.
>> 
>> There is no problem with ZIL devices, they reports ashift: 12
>> 
>> 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
>> 
>> Problem with cache devices only, but in zdb output tere is nothing at all about them.
>> 
>> --- Исходное сообщение --- От кого: "Steven Hartland" < killing at multiplay.co.uk >
>> Дата: 16 сентября 2013, 14:18:31
>> 
>> 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 <pool>
>> 
>>   Regards
>>   Steve
>> ----- Original Message ----- From: "Borja Marcos" <
>> 
>> --- Дмитрий Макаров
>> 
>> 
>> --- Дмитрий Макаров
> 
> 
> ================================================
> 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 at multiplay.co.uk.
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"