From owner-freebsd-scsi@freebsd.org Mon Jun 6 08:51:43 2016 Return-Path: Delivered-To: freebsd-scsi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F4CDB6D900 for ; Mon, 6 Jun 2016 08:51:43 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 486991798 for ; Mon, 6 Jun 2016 08:51:42 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.36] (izaro.sarenet.es [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPSA id A72EA9DD7CD; Mon, 6 Jun 2016 10:42:32 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Avago LSI SAS 3008 & Intel SSD Timeouts From: Borja Marcos In-Reply-To: Date: Mon, 6 Jun 2016 10:42:32 +0200 Cc: freebsd-scsi@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <08C01646-9AF3-4E89-A545-C051A284E039@sarenet.es> References: <30c04d8b-80cb-c637-26dc-97caebad3acb@mindpackstudios.com> To: Steven Hartland X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 08:51:43 -0000 > On 03 Jun 2016, at 23:49, Steven Hartland = wrote: >=20 > First thing would be to run gstat with -d to see if you're actually = stacking up deletes, a symptom of which can be r/w dropping to zero. >=20 > If you are seeing significant deletes it could be a FW issue on the = drives. Hmm. I=E2=80=99ve suffered that badly with Intel P3500 NVMe drives, = which suffer at least from a driver problem: trims are not coalesced.=20 However I didn=E2=80=99t experience command timeouts. Reads and, = especially, writes, stalled badly. A quick test for trim related trouble is setting the sysctl variable = vfs.zfs.vdev.bio_delete_disable to 1. It doesn=C2=B4t require a reboot and you can quickly compare results. In my case, a somewhat similar problem in an IBM server was caused by a = faulty LSI3008 card it seems. As I didn=C2=B4t have spare LSI3008 cards at the time I replaced it by a LSI2008 and everything works perfectly. = Before anyone chimes in suggesting card incompatibility of some sort, I have a twin system with a LSI3008 working like a charm. ;) Borja.