Darren J Moffat wrote:
> Jeff Bonwick wrote:
> 
>> The L2ARC seems more complex because allocation is done by the feed 
>> thread,
>> not in the context of any particular dataset doing I/O.  The feed thread
>> has no way of knowing on whose behalf blocks exist.  So it would have to
>> operate as it does today, caching everything that falls out of the ARC.
>> It's not clear to me how the L2ARC policy can be anything other than a
>> pool-wide property.
> 
> 
> I had to solve a very similar problem for enabling encryption support in 
> the L2ARC.  I did this by using the internal flags field in the ARC 
> header to record wither or not the the initial read/write in the ARC was 
> for an encrypted dataset.  I think this case is slightly tricker but I 
> can see how it could be done.
> 
Yup, this was Eric's proposed solution: an L2ARC_IS_CACHABLE flag that
is added when the arc buffer is allocated.

Reply via email to