zfs discuss - Jan 2010 - primarycache=off, secondarycache=all

In the case of a ZVOL with the following settings:

primarycache=off, secondarycache=all

How does the L2ARC get populated if the data never makes it to ARC ? Is this
even a valid configuration?

The reason I ask is I have iSCSI volumes for NTFS, I intend to use an SSD for
l2arc. If something is read from the iSCSI device, then chances are Windows (or
whatever OS) will cache it for a while in its own cache. It is unlikely that the
data will be needed soon (under normal circumstances).

Thus I would like it to avoid polluting the ARC with non-relevant data, but then
the question is, how will that data make it to the L2ARC.
-- 
This message posted from opensolaris.org

On Wed, Jan 27, 2010 at 02:47:47PM -0800, Christo Kutrovsky
wrote:
> In the case of a ZVOL with the following settings:
> 
> primarycache=off, secondarycache=all
> 
> How does the L2ARC get populated if the data never makes it to ARC ?
> Is this even a valid configuration? 
It''s valid, I assume, in the sense that it can be set.

However, I''ve also assumed that if the data never gets into primary
cache, it will never be evicted into L2.  

That''s glossing over the details, which may be important - for
example, I don''t think ZFS is structured to work with data
that''s
*not* in ARC, so it may be that primarycache=off basically marks data
for immediate eviction - where it still may be a candidate for l2.
> The reason I ask is I have iSCSI volumes for NTFS, I intend to use
> an SSD for l2arc. If something is read from the iSCSI device, then
> chances are Windows (or whatever OS) will cache it for a while in
> its own cache. It is unlikely that the data will be needed soon
> (under normal circumstances).   
> 
> Thus I would like it to avoid polluting the ARC with non-relevant
> data, but then the question is, how will that data make it to the
> L2ARC. 
With the setup above, I suspect it won''t.  It would be nice to get an
authoritative confirmation of that, of course.

Regardless, to your original requirement, it sounds like you''re
looking for a tuning knob to give further hints to the ARC algorithm,
about which pages to evict first.  More knobs are not always better.
ARC should in theory already do a good job of telling the difference
between "accessed recently" and "accessed frequently". 
Evictees from
both states can go to l2arc.

Look at it another way: If the client cache in the windows machine
works as you expect (and I expect it would, at least for some data),
the best hint you can give to ARC that these blocks are not needed is
to access *other* data.

So, measure and analyse.

--
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100128/7451ee1e/attachment.bin>

Thanks for info Dan,


I will test it out, but won''t be anytime soon. Waiting for that SSD.
-- 
This message posted from opensolaris.org