Matthew Ahrens wrote:
> Jeff Bonwick wrote:
>
>>> Yup, this was Eric's proposed solution: an L2ARC_IS_CACHABLE flag that
>>> is added when the arc buffer is allocated.
>>
>>
>> That doesn't seem quite right. Consider this sequence of events,
>> where C and NC are two datasets with and without L2ARC caching:
>>
>> NC: reads block B, puts it in the ARC with L2ARC_IS_CACHEABLE clear
>> C: reads block B, but since it's not the one doing the allocation,
>> doesn't set L2ARC_IS_CACHEABLE
>> feed thread: discards block B
>> C: reads block B, going to disk instead of L2ARC as it should have
>>
>> But if C had read the block before NC, everything would have been fine.
>>
>> It seems to me that the order of access should not determine the policy.
>> Whenever a block is looked up in the ARC, if the caller wants that block
>> to be L2ARC cached, then the L2ARC_IS_CACHEABLE flag should be ORed in.
>> In short, there are three possibly policies:
>>
>> (1) If *anyone* wants the block cached, it is cached.
>> (2) If *anyone* doesn't want the block cached, it is not cached.
>> (3) It might or might not be cached depending who gets there first.
>>
>> To me, (1) is the only policy that makes sense, or is even defensible.
>
>
> Agreed. Seems like this could be accomplished in the above scenario by
> having C set L2ARC_IS_CACHEABLE when it hits in the cache.
>
Indeed... and looking back at the actual webrev (instead of relying on
my memory) I see that Eric actually implemented something like (2)
above. That is, he uses a ARC_DONT_L2CACHE flag and sets it when NC
gets a hit.
