Indeed they are there, shown with 1 second interval. So, it is the client's fault after all. I'll have to see whether it is somehow possible to get the server to write cached data sooner (and hopefully asynchronous), and the client to issue commits less often. Luckily I can live with the current behavior (and the SSDs shouldn't give out any time soon even being used like this), if it isn't possible to change it.
Thanks for all the help, Tim On Thu, Jun 14, 2012 at 10:30 PM, Phil Harman <phil.har...@gmail.com> wrote: > On 14 Jun 2012, at 23:15, Timothy Coalson <tsc...@mst.edu> wrote: > >>> The client is using async writes, that include commits. Sync writes do not >>> need commits. >> >> Are you saying nfs commit operations sent by the client aren't always >> reported by that script? > > They are not reported in your case because the commit rate is less than one > per second. > > DTrace is an amazing tool, but it does dictate certain coding compromises, > particularly when it comes to output scaling, grouping, sorting and > formatting. > > In this script the commit rate is calculated using integer division. In your > case the sample interval is 5 seconds, so up to 4 commits per second will be > reported as a big fat zero. > > If you use a sample interval of 1 second you should see occasional commits. > We know they are there because we see a non-zero commit time. > > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
