On Jan 8, 2012, at 5:10 PM, Jim Klimov wrote:
> 2012-01-09 4:14, Richard Elling пишет:
>> On Jan 7, 2012, at 8:59 AM, Jim Klimov wrote:
>>
>>> I wonder if it is possible (currently or in the future as an RFE)
>>> to tell ZFS to automatically read-ahead some files and cache them
>>> in RAM and/or L2ARC?
>>
>> See discussions on the ZFS intelligent prefetch algorithm. I think Ben
>> Rockwood's
>> description is the best general description:
>> http://www.cuddletech.com/blog/pivot/entry.php?id=1040
>>
>> And a more engineer-focused description is at:
>> http://www.solarisinternals.com/wiki/index.php/ZFS_Performance#Intelligent_prefetch
>> -- richard
>
> Thanks for the pointers. While I've seen those articles
> (in fact, one of the two non-spam comments in Ben's
> blog was mine), rehashing the basics is always useful ;)
>
> Still, how does VDEV prefetch play along with File-level
> Prefetch?
Trick question… it doesn't. vdev prefetching is disabled in opensolaris b148,
illumos,
and Solaris 11 releases. The benefits of having the vdev cache for large
numbers of
disks does not appear to justify the cost. See
http://wesunsolve.net/bugid/id/6684116
https://www.illumos.org/issues/175
> For example, if ZFS prefetched 64K from disk
> at the SPA level, and those sectors luckily happen to
> contain "next" blocks of a streaming-read file, would
> the file-level prefetch take the data from RAM cache
> or still request them from the disk?
As of b70, vdev_cache only contains metadata. See
http://wesunsolve.net/bugid/id/6437054
> In what cases would it make sense to increase the
> zfs_vdev_cache_size? Does it apply to all disks
> combined, or to each disk (or even slice/partition)
> separately?
It applies to each leaf vdev.
>
> In fact, this reading got me thinking that I might have
> a fundamental misunderstanding lately; hence a couple
> of new yes-no questions arose:
>
> Is it true or false that: ZFS might skip the cache and
> go to disks for "streaming" reads? (The more I think
> about it, the more senseless this sentence seems, and
> I might have just mistaken it with ZIL writes of bulk
> data).
Unless the primarycache parameter is set to none, reads
will look in the ARC first.
>
> Is it true or false that: ARC might evict cached blocks
> based on age (without new reads or other processes
> requiring the RAM space)?
False. Evictions occur when needed.
NB, I'm not sure of the status of the Solaris 11 ARC no-grow issue.
As that code is not open sourced, and we know that Oracle rewrote
some of the ARC code, all bets are off.
> And I guess the generic answer to my original question
> regarding intelligent pre-fetching of whole files is
> that this should be done by scripts outside ZFS itself,
> and that the read-prefetch as well as ARC/L2ARC is all
> in place already. So if no other IOs occur, the disks
> may spin down... if only not for those "nasty" writes
> that may sporadically occur and which I'd love to see
> pushed out to dedicated ZILs ;)
I've setup external prefetching for specific use cases. Spin-down
is another can of worms…
-- richard
--
ZFS and performance consulting
http://www.RichardElling.com
illumos meetup, Jan 10, 2012, Menlo Park, CA
http://www.meetup.com/illumos-User-Group/events/41665962/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
