On 2/4/14, 5:59 PM, Andriy Gapon wrote:
> on 04/02/2014 19:40 Saso Kiselkov said the following:
>> On 2/4/14, 5:32 PM, Andriy Gapon wrote:
>>> on 29/01/2014 17:32 Andriy Gapon said the following:
>>>> The code in arc_hdr_destroy destroys b_l2hdr header, but the actual data is
>>>> still pointed to by b_buf.  arc_hdr_destroy then calls arc_buf_destroy, 
>>>> which
>>>> uses arc_buf_data_free to free the data.  The data can either be freed
>>>> immediately or, if the data is still in use by an L2ARC write zio, it can 
>>>> be put
>>>> on l2arc_free_on_write list, so that it is freed later when the zio is 
>>>> done.
>>>>
>>>> The code seems to be unchanged by the L2ARC compression commit and the 
>>>> code is
>>>> sound as long as there is no compression.
>>>> But if L2ARC compression is enabled, then in addition to the original data
>>>> buffer we now also have a buffer with compressed data.  That buffer is 
>>>> pointed
>>>> to by b_tmp_cdata in l2arc_buf_hdr_t.
>>>> There has to be some additional code to free the compressed buffer in the
>>>> arc_hdr_destroy code path described above.  b_tmp_cdata must be passed 
>>>> along
>>>> with b_data via l2arc_free_on_write list and b_tmp_cdata must then be 
>>>> freed in
>>>> l2arc_do_free_on_write.
>>>
>>> I suggested the following diagnostic patch:
>>> http://people.freebsd.org/~avg/l2arc-b_tmp_cdata-diag.patch
>>>
>>> With the patch applied there is the following panic (sorry for poor 
>>> quality):
>>> http://oi59.tinypic.com/sfctvc.jpg
>>>
>>> I am trying to get more details.
>>
>> Now that I think about it a bit more, I don't think it's correct to have
>> this assertion in there. It is entirely possible that other threads come
>> across the L2ARC write head (but they should skip it). This happens
> 
> Apologies, but have you conflated the threads again? :-)
> The patch and the panic have nothing to do with the L2ARC write head.
> 

Sorry, my bad. Ignore me :)

-- 
Saso
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer

Reply via email to