Date: Tue, 15 Jul 2008 20:27:43 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Steve Bertrand <steve@ibctech.ca> Cc: freebsd-stable@freebsd.org Subject: Re: taskqueue timeout Message-ID: <200807160327.m6G3Rh57012575@apollo.backplane.com> References: <487CCD46.8080506@ibctech.ca> <200807151711.m6FHBgVO007481@apollo.backplane.com> <487CF077.2040201@ibctech.ca> <487CFA08.5000308@ibctech.ca> <200807151955.m6FJtf77008969@apollo.backplane.com> <487D5D08.9070102@ibctech.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
:...
:> and see if the problem reoccurs with just two drives.
:
:... I knew that was going to come up... my response is "I worked so hard
:to get this system with ZFS all configured *exactly* how I wanted it".
:
:To test, I'm going to flip to 30 as per Matthews recommendation, and see
:how far that takes me. At this time, I'm only testing by backing up one
:machine on the network. If it fails, I'll clock the time, and then
:'reformat' with two drives.
:
:Is there a technical reason this may work better with only two drives?
:
:Is there anyone interested to the point where remote login would be helpful?
:
:Steve
This issue is vexing a lot of people.
Setting the timeout to 30 will not effect performance, but it will
cause a 30 second delay in recovery when (if) the problem occurs.
i.e. when the disk stalls it will just sit there doing nothing for
30 seconds, then it will print the timeout message and try to recover.
It occurs to me that it might be beneficial to actually measure the
disk's response time to each request, and then graph it over a period
of time. Maybe seeing the issue visually will give some clue as to the
actual cause.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807160327.m6G3Rh57012575>