On Nov 26, 2007 7:57 PM, Richard Elling <[EMAIL PROTECTED]> wrote:
> 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
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
On Nov 26, 2007 8:41 PM, Joe Little <[EMAIL PROTECTED]> wrote:
> I was playing with a Gigabyte i-RAM card and found out it works great
> to improve overall performance when there are a lot of writes of small
> files over NFS to such a ZFS pool.
>
> However, I noted a frequent situation in periods o
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.
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 i
I was playing with a Gigabyte i-RAM card and found out it works great
to improve overall performance when there are a lot of writes of small
files over NFS to such a ZFS pool.
However, I noted a frequent situation in periods of long writes over
NFS of small files. Here's a snippet of iostat during
