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. -- Andriy Gapon _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
