on 05/02/2014 00:33 Saso Kiselkov said the following:
> Ah, now I understand what's going on. The application is dirtying a dbuf
> who's backing ARC buffer is currently in-flight into the L2ARC, so it
> needs to be discarded. Instead of going through arc_evict, it calls
> arc_release directly to dispose of the buffer, but it doesn't clear the
> in-flight compressed data.
> 
> So the solution would be obvious: if there's a compressed buffer, call
> l2arc_release_cdata_buf to clear it.

I think that this change would not be as trivial as it may sound.
Since the buffer is in flight (ARC_L2_WRITING) the compressed data is still
required by a zio, so l2arc_release_cdata_buf() can't be called immediately.
Rather, [something like] arc_buf_data_free() + l2arc_do_free_on_write() should
be used for delayed invocation of l2arc_release_cdata_buf().  But
l2arc_release_cdata_buf() takes a pointer to arc_buf_hdr_t as its argument and
uses b_l2hdr to get to b_tmp_cdata and b_compress.  So, b_l2hdr should not be
cleared / freed in arc_release(). And so on.

I am sure that it is not too hard to glue together a solution, but it is not
trivial either.

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

Reply via email to