Chris Csanady writes: > On 5/26/06, Bart Smaalders <[EMAIL PROTECTED]> wrote: > > > > There are two failure modes associated with disk write caches: > > Failure modes aside, is there any benefit to a write cache when command > queueing is available? It seems that the primary advantage is in allowing > old ATA hardware to issue writes in an asynchronous manner. Beyond > that, it doesn't really make much sense, if the queue is deep enough.
The write cache decreases the effective latency by a very large factor (> 50 X on a quick test). But I guess your point is more, about comparing "write_cache on + flush" to "write_cache off + ordered tags" ? > > > ZFS enables the write cache and flushes it when committing transaction > > groups; this insures that all of a transaction group appears or does > > not appear on disk. > > How often is the write cache flushed, and is it synchronous? Unless I am > misunderstanding something, wouldn't it be better to use ordered tags, and > avoid cache flushes all together? Write cache is flushed everytime ZFS needs to insure stable storage. For every zil commit we flush the cache. This insure for instance that O_DSYNC writes are completed before syscall returns. So flush when required and it's synchronous (flush then wait for flush completion). What benefit do you see in the use of ordered tags over the current situation ? > > Also, does ZFS disable the disk read cache? It seems that this would be > counterproductive with ZFS. It's on on my system. What don't you like here ? > > Chris > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
