Joe Little wrote: > On Nov 26, 2007 7:00 PM, Richard Elling <[EMAIL PROTECTED]> wrote: > >> I would expect such iostat output from a device which can handle >> only a single queued I/O to the device (eg. IDE driver) and an I/O >> is stuck. There are 3 more I/Os in the wait queue waiting for the >> active I/O to complete. The %w and %b are measured as the percent >> of time during which an I/O was in queue. The svc_t is 0 because >> the I/O is not finished. >> >> By default, most of the drivers will retry I/Os which don't seem to >> finish, but the retry interval is often on the order of 60 seconds. >> If a retry succeeds, then no message is logged to syslog, so you >> might not see any messages. But just to be sure, what does >> fmdump (and fmdump -e) say about the system? Are messages >> logged in /var/adm/messages? >> > > nothing with fmdump or /var/adm/messages. Your answer explains why its > 60 seconds or so. What's sad is that this is a ramdisk so to speak, > albeit connected via SATA-I to the sil3124. Any way to isolate this > further? Anyway to limit i/o timeouts to a drive? this is just two > sticks of ram.. ms would be fine :) >
I suspect a bug in the driver or firmware. It might be difficult to identify if it is in the firmware. A pretty good white paper on storage stack timeout tuning is available at BigAdmin: http://www.sun.com/bigadmin/features/hub_articles/tuning_sfs.jsp But it won't directly apply to your case because you aren't using the ssd driver. I'd wager the cmdk driver is being used for your case and I'm not familiar with its internals. prtconf -D will show which driver(s) are in use. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
