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