> From: Jim Dunham [mailto:james.dun...@oracle.com] > > ZFS only uses system RAM for read caching,
If your email address didn't say oracle, I'd just simply come out and say you're crazy, but I'm trying to keep an open mind here... Correct me where the following statement is wrong: ZFS uses system RAM to buffer async writes. Sync writes must hit the ZIL first, and then the sync writes are put into the write buffer along with all the async writes to be written to the main pool storage. So after sync writes hit the ZIL and the device write cache is flushed, they too are buffered in system RAM. > as all writes must be written to > some form of stable storage before acknowledged. If a vdev represents a > whole disk, ZFS will attempt to enable write caching. If a device does not > support write caching, the attempt to set wce fails silently. Here is an easy analogy to remember basically what you said: "format -e" can control the cache settings for c0t0d0, but cannot control the cache settings for c0t0d0s0 because s0 is not actually a device. I contend: Suppose you have a disk with on-disk write cache enabled. Suppose a sync write comes along, so ZFS first performs a sync write to some ZIL sectors. Then ZFS will issue the cache flush command and wait for it to complete before acknowledging the sync write; hence the disk write cache does not benefit sync writes. So then we start thinking about async writes, and conclude: The async writes were acknowledged long ago, when the async writes were buffered in ZFS system ram, so there is once again, no benefit from the disk write cache in either situation. That's my argument, unless somebody can tell me where my logic is wrong. Disk write cache offers zero benefit. And disk read cache only offers benefit in unusual cases that I would call esoteric. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
