[zfs-discuss] zfs primarycache and secondarycache properties [PSARC/2008/393 FastTrack timeout 06/27/2008]

[Darren Reed]

eric kustarz wrote:
>
> On Jun 25, 2008, at 11:49 AM, Darren Reed wrote:
>
>> This would seem to be a significant use case for the model of having
>> non-overlapping data types in each of the two caches.  Since no reply
>> was received on zfs-discuss, I'm redirecting it to psarc to indicate 
>> that
>> this question isn't closed.
>
> I see some comments, but no direct question.  So what is the question?

If the primary and secondary cache are different media, especially in 
the case
of one being non-volatile, shouldn't it be possible to allow the user to 
specify
that they want to use the non-volatile cache for meta data without requiring
them to forgo caching user data in a volatile cache?

Darren

>> Darren J Moffat wrote:
>>> Darren Reed wrote:
>>>
>>>> So I spent some time thinking about different directions you could 
>>>> build
>>>> on this in the future, for example:
>>>> 1) controlling the size of the ARC/L2ARC by controlling the cache size
>>>> 2) specifying different backing storage for primary/secondary cache
>>>> 3) having more than two levels of cache
>>>> ...none of which is precluded by current efforts.
>>>>
>>>> With (2), if the backing storage for each cache is different and it 
>>>> is slower
>>>> to access the secondary cache than the primary, then you may not want
>>>> metadata to be stored in the secondary cache for performance reasons.
>>>>
>>>> As an example, you might be using NVRAM (be it flash or otherwise)
>>>> for the primary cache and ordinary RAM for the secondary.  In this 
>>>> case
>>>> you probably don't want any metadata to be stored in the secondary
>>>> cache (power failure issues) but  the same may not hold for user data.
>>>> But I'm probably wrong about that.
>>>>
>>>
>>> I doubt you would be, the primarycache is system memory not a cache 
>>> device.  The secondarycache is the L2ARC devices specified with the 
>>> "cache" vdev type to zpool so your examle would be the otherway around.
>>>
>>>
>