2012-01-08 19:15, John Martin пишет:
On 01/08/12 09:30, Edward Ned Harvey wrote:
In the case of your MP3 collection... Probably the only thing you can
do is
to write a script which will simply go read all the files you predict
will
be read soon. The key here is the prediction - There's no way ZFS or
solaris, or any other OS in the present day is going to intelligently
predict which files you'll be requesting soon.
The other prediction is whether the blocks will be reused.
If the blocks of a streaming read are only used once, then
it may be wasteful for a file system to allow these blocks
to placed in the cache. If a file system purposely
chooses to not cache streaming reads, manually scheduling a
"pre-read" of particular files may simply cause the file to be read
from disk twice: on the manual pre-read and when it is read again
by the actual application.
I believe Joerg Moellenkamp published a discussion
several years ago on how L1ARC attempt to deal with the pollution
of the cache by large streaming reads, but I don't have
a bookmark handy (nor the knowledge of whether the
behavior is still accurate).
Well, this point is valid for intensively-used servers - but
then such blocks might just get evicted from the caches by
newer and/or more-frequently-used blocks.
However for smaller servers, such as home NASes which have
about one user overall, pre-reading and caching files even
for a single use might be an objective per se - just to let
the hard-disks spin down. Say, if I sit down to watch a
movie from my NAS, it is likely that for 90 or 120 minutes
there will be no other IO initiated by me. The movie file
can be pre-read in a few seconds, and then most of the
storage system can go to sleep.
//Jim
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
