> on FreeBSD. This is inefficient in a number of ways. I have also seen > things that make me suspicious that it is not caching properly even when > you tune it to be "large enough" (if possible given memory constraints), > but I haven't confirmed this. FWIW, I have had some suspiciouns here too strictly from a user-centric point of view. Most recently I found that I could not get ZFS to cache enough such that "pkg_info" would not have to get down on disk (thus making all package installation and similar dead-slow, due to the number of times /var/db/pkg is accesses in deep dependency hierarchies). In this case I tended up killing as much as I could on the machine (web browsers, MUA:s, whatever else), on the theory that large files being kept open would affect the caching strategy. Even after killing most stuff and after multiple pkg_info:s (to accumulate frequency), it was still only caching enough for perhaps 20% of what pkg_info needs on this machine (when invoked without arguments, listing all packages). I don't know if this is just a result of giving too much weight to past history or if there is an actual bug somewhere; but the perceived end-result for me as a user was clearly significantly worse than a plain page-wise LRU would have given. I ended up rebooting the machine to get package upgrades to complete within a reasonable amount of time. This was on my 64 bit desktop machine with: vm.kmem_size_max="1258291200" vfs.zfs.prefetch_disable="1" vfs.zfs.arc_max="838860800" -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller_at_infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey_at_scode.org E-Mail: peter.schuller_at_infidyne.com Web: http://www.scode.org
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:30 UTC