Date: Mon, 6 Jun 2016 10:42:32 +0200 From: Borja Marcos <borjam@sarenet.es> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-scsi@freebsd.org Subject: Re: Avago LSI SAS 3008 & Intel SSD Timeouts Message-ID: <08C01646-9AF3-4E89-A545-C051A284E039@sarenet.es> In-Reply-To: <b30f968c-cc41-f7de-5a54-35bed961e65a@multiplay.co.uk> References: <30c04d8b-80cb-c637-26dc-97caebad3acb@mindpackstudios.com> <b30f968c-cc41-f7de-5a54-35bed961e65a@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 03 Jun 2016, at 23:49, Steven Hartland <killing@multiplay.co.uk> = 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?08C01646-9AF3-4E89-A545-C051A284E039>