On Wed, Aug 09, 2006 at 03:29:05PM -0700, Dave Fisk wrote: > > For example the COW may or may not have to read old data for a small > I/O update operation, and a large portion of the pool vdev capability > can be spent on this kind of overhead.
This is what the 'recordsize' property is for. If you have a workload that works on large files in very small sized chunks, setting the recordsize before creating the files will result in a big improvement. > Also, on read, if the pattern is random, you may or may not > receive any benefit from the 32 KB to 128 KB reads on each disk of the > pool vdev on behalf of a small read, say 8 KB by the application, > again lots of overhead potential. We're evaluating the tradeoffs on this one. The original vdev cache has been around forever, and hasn't really been reevaluated in the context of the latest improvements. See: 6437054 vdev_cache: wise up or die The DMU-level prefetch code had to undergo a similar overhaul, and was fixed up in build 45. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
