> 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.
Jeff
