bfriesen, Andrew brought up NVRAM by refering me to the following link:
Also, NFS to ZFS filesystems will run slowly under certain conditions -including with the default configuration. See this link for more information: http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Cache_Flushes This section discusses exclusively how ZFS cache flushes, which can be triggered by NFS requests or policies, interacts with NVRAMs unproductively, and how the flushes can be controlled to improve performance. Since the NVRAMs are Non Volatile, the flushes are not necessary to preserve data integrity anyway. Not worth tracing the chain to see how you and I got tangled in this. One of us make an inappropriate association or didn't follow a sub-thread. Sorry for the confusion. ----------- Regarding the cache, right now there is 150MB of free memory not being used by ANYBODY, so I don't think there is a shortage of memory for the ZFS cache... and 150MB >> 128K, or even a whole slew of 128K blocks. Also, the yellow light that blinks when the disk is accessed is off 90% of the time minimum. When it was almost frozen, the disk almost never blinked (one real quick one every minute or two!) Nothing is accessing the disk to re-obtain anything! Otherwise, yes you would have a good point about re-fetching various file structure stuff. (Good thought). Fragmentation of kernel memory would be a good one. Wouldn't it get fragmented after 6 months or so of everyday use anyway? It must de-frag itself somehow. You bring up an excellent observation. When it was super-slow, free RAM was down to 15MB, although that still seems large compared to 32K or 128K blocks. Remember, the system is not doing ANYTHING else. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
