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.

Attachment: pgpmFuXepzig7.pgp
Description: PGP signature

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to