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:
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
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
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