Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 3 Aug 2012 14:17:09 -0700
From:      Garrett Cooper <yanegomi@gmail.com>
To:        Mike Tancsa <mike@sentex.net>
Cc:        current@freebsd.org
Subject:   Re: [PATCH] Add locking to twe(4) so it no longer uses Giant
Message-ID:  <9C0F7DB1-E75B-42A9-90A4-22599F99E15E@gmail.com>
In-Reply-To: <501C37D3.5040704@sentex.net>
References:  <201208031418.57941.jhb@freebsd.org> <CAN6yY1t824WcE3J_9%2BG_VK7QNWr=yuxLdBLMyB_wFZB-OaqrTA@mail.gmail.com> <201208031539.47735.jhb@freebsd.org> <501C37D3.5040704@sentex.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 3, 2012, at 1:42 PM, Mike Tancsa wrote:

> On 8/3/2012 3:39 PM, John Baldwin wrote:
>> On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote:
>>> I'll try to find time to try it later today, but I'm in the middle =
of
>>> budget wrangling and I can't make any promises.
>>>=20
>>> Before I try, will these patches apply to the twe driver in
>>> 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July =
18.
>>> I really don't have time to install current right now.
>>=20
>> I believe the patches should apply fine on 8 and 9.  If you use it on =
8 or 9
>> please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least =
for
>> initial testing.  Thanks!
>=20
> Seems to apply to RELENG_9 just fine.  Are there any stress tests you
> suggest I run that might expose some bugs ? The machine is not
> production yet, so its ok to crash it.

	Looking really quickly at the patch, it looks like most of the =
locking changes are made around management pieces, and not data handling =
pieces (but I might have missed something).
	If there's a tool for poking at the drives/controller, I would =
use that, plus camcontrol. Of course you want a data intensive workload =
(iometer/iozone/xdd with async and sync mode, random reads and =
sequential reads, etc), and maybe resort to manual testing like pulling =
drives (power, data) if you don't mind creating failures. If you have =
some failed/failing drives kicking around, that would be a good test as =
well (see that all/some of the failure paths are properly stimulated).
	Any variance or combining of these tests will help build =
confidence in the change being proposed.
HTH,
-Garrett=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9C0F7DB1-E75B-42A9-90A4-22599F99E15E>