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. > because while writing new buffers, we release l2arc list locks to enable > others read access to the L2ARC while we're waiting for our latest write > to commit. We then require the lock in write_done to clean up after > ourselves... > > I need to dive into this code again, but I'm just too busy right now > with other stuff. -- Andriy Gapon _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
