2012-01-11 1:26, Jim Klimov пишет:
To follow on the subject of VDEV caching, even if
only of metadata, in oi_148a, I have found the
disabling entry in /etc/system of the LiveUSB:
set zfs:zfs_vdev_cache_size=0
Now that I have the cache turned on and my scrub
continues, cache efficiency so far happens to be
75%. Not bad for a feature turned off by default:
# kstat -p zfs:0:vdev_cache_stats
zfs:0:vdev_cache_stats:class misc
zfs:0:vdev_cache_stats:crtime 60.67302806
zfs:0:vdev_cache_stats:delegations 22619
zfs:0:vdev_cache_stats:hits 32989
zfs:0:vdev_cache_stats:misses 10676
zfs:0:vdev_cache_stats:snaptime 39898.161717983
//Jim
And at this moment I can guess the caching effect
becomes incredible (at least for a feature disabled
and dismissed at useless/harmful) - if I read the
numbers correctly, a 99+% cache hit ratio with
just VDEV prereads:
# kstat -p zfs:0:vdev_cache_stats
zfs:0:vdev_cache_stats:class misc
zfs:0:vdev_cache_stats:crtime 60.67302806
zfs:0:vdev_cache_stats:delegations 23398
zfs:0:vdev_cache_stats:hits 1309308
zfs:0:vdev_cache_stats:misses 11592
zfs:0:vdev_cache_stats:snaptime 89207.679698161
True, the task (scrubbing) is metadata-intensive :)
Still, for the future, when beginning a scrub the
system might auto-tune or at least suggest to enable
the VDEV prefetch, perhaps with larger strokes)...
BTW, what does the "delegations" field mean? ;)
--
+============================================================+
| |
| Климов Евгений, Jim Klimov |
| технический директор CTO |
| ЗАО "ЦОС и ВТ" JSC COS&HT |
| |
| +7-903-7705859 (cellular) mailto:jimkli...@cos.ru |
| CC:ad...@cos.ru,jimkli...@gmail.com |
+============================================================+
| () ascii ribbon campaign - against html mail |
| /\ - against microsoft attachments |
+============================================================+
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
