On Sat, 29 Nov 2008, Ray Clark wrote:
> through the buffer. Whether the buffer is 128MB or 4GB, once the
> buffer is full the client will have to wait until something flows
> out to the disk. So the system runs at the speed of the slowest
> component. If accesses are done only once, caches don't help. A
> buffer helps only to smooth out localized chunkyness.
You are wrong in assuming that a "write only" situation does not
benefit immensely from caching. ZFS tries to write data 128K at a
time. Without caching, the user data aggregation into 128K does not
work well when NFS provides only 8-32K at a time. ZFS likes to buffer
up a number of blocks (if allowed) and then write them to disk in
optimum order. Also, the filesystem metadata and structures need to be
cached or else ZFS needs to continually go to disk in order to
re-obtain this information that it otherwise would already have in
RAM. Since disk access is 10,000 times slower than RAM, having to go
to the disk even one more time is a *huge* performance loss.
Since you have very little RAM, it is is quite likely that your kernel
data memory is becoming "fragmented" so that acquiring and freeing
memory is less optimum than normal.
Regardless, ZFS is a very memory-oriented filesystem implementation
which requires more RAM than most other filesystems. Good old UFS
uses less RAM.
> Regarding the NVRAM discussion, what does this have to do with my
> situation with rotating magnetic disks with tiny 8MB embedded
> volatile caches? The behavior of disks or storage subsystems with
> NVRAM are not pertinent to my situation! Or do I have something
> backwards? -- This message posted from opensolaris.org
I am not sure why you brought up NVRAM if it was not pertinent to your
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
zfs-discuss mailing list