On Wed, 24 Jun 2009, Ross wrote:
Wouldn't it make sense for the timing technique to be used if the data is coming in at a rate slower than the underlying disk storage?
I am not sure how zfs would know the rate of the underlying disk storage without characterizing it for a while with actual I/O. Regardless, buffering up to 3GB of data and then writing it all at once does not make sense regardless of the write rate of the underlying disk storage. It results in the I/O channel being completely clogged for 3-7 seconds.
But then if the data starts to come at a faster rate, ZFS needs to start streaming to disk as quickly as it can, and instead of re-ordering writes in blocks, it should just do the best it can with whatever is currently in memory. And when that mode activates, inbound data should be throttled to match the current throughput to disk.
In my case, the data is produced at a continual rate (40-80MB/s). ZFS batches it up in a huge buffer for 30 seconds and then writes it all at once. It is not clear to me if the writer is blocking, or if the reader is blocking due to ZFS's sudden huge use of the I/O channel. I am sure that I could find the answer via dtrace.
That preserves the efficient write ordering that ZFS was originally designed for, but means a more graceful degradation under load, with the system tending towards a steady state of throughput that matches what you would expect from other filesystems on those physical disks.
In this case the files are complete and ready to be written in optimum order. Of course ZFS has no way to know that the application won't try to update them again.
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
