Date: Wed, 27 Nov 2013 10:42:29 +0100 From: krichy@cflinux.hu To: freebsd-scsi@freebsd.org Subject: Fwd: ssd for zfs Message-ID: <ef7e350c5edc68ba6c0a33a171c62a2a@cflinux.hu>
next in thread | raw e-mail | index | archive | help
Dear SCSI dev team, I bought an SSD for my ZFS filesystem to use it as a ZIL. I've tested it under linux, and found that it can handle around 1400 random synchronized write IOPS. Then I placed it into my freebsd 9.2 box, and after attaching it as a ZIL, my zpool only performs 100 (!) write iops. I've attached it to an AHCI controller and to an LSI 1068 controller, on both it behaves the same. So I expect that something in the scsi layer is different, FreeBSD is handling this device slower, but actually it can handle the 1400 iops as tested under linux. I've attached the simple script I used to do the benchmark. basically, on linux and bsd also I've added the SSD as a LOG device to an existing pool, and run the test on a filesystem in that pool. Please give some advice where to go, how to debug, and how to improve FreeBSD's performance with this drive. The device is: # camcontrol identify ada3 pass4: <STEC MACH16 M16SD2S-50UI 00000299> ATA-8 SATA 2.x device pass4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 512bytes) protocol ATA/ATAPI-8 SATA 2.x device model STEC MACH16 M16SD2S-50UI firmware revision 00000299 serial number STM0001680E8 WWN 5000a7203006f8e5 media serial number STEC MACH16 M16SD2S-50UI STM00 cylinders 16383 heads 15 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 97696368 sectors LBA48 supported 97696368 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload no yes free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 8 DSM - deterministic read yes any value Host Protected Area (HPA) yes no 97696368/97696368 HPA - Security no Regards, Kojedzinszky Richard From owner-freebsd-scsi@FreeBSD.ORG Wed Nov 27 14:14:41 2013 Return-Path: <owner-freebsd-scsi@FreeBSD.ORG> Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 406321C1 for <freebsd-scsi@freebsd.org>; Wed, 27 Nov 2013 14:14:41 +0000 (UTC) Received: from pi.nmdps.net (pi.nmdps.net [IPv6:2a01:be00:10:201:0:80:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 0736622D3 for <freebsd-scsi@freebsd.org>; Wed, 27 Nov 2013 14:14:41 +0000 (UTC) Received: from pi.nmdps.net (localhost [127.0.0.1]) (Authenticated sender: krichy@cflinux.hu) by pi.nmdps.net (Postfix) with ESMTPSA id 3E66F10E7 for <freebsd-scsi@freebsd.org>; Wed, 27 Nov 2013 15:14:40 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 27 Nov 2013 15:14:38 +0100 From: krichy@cflinux.hu To: freebsd-scsi@freebsd.org Subject: Fwd: Re: ssd for zfs Message-ID: <0b12c19b8832c72369ff7244d7231846@cflinux.hu> X-Sender: krichy@cflinux.hu User-Agent: Roundcube Webmail/0.9.5 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: SCSI subsystem <freebsd-scsi.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-scsi>, <mailto:freebsd-scsi-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-scsi/>; List-Post: <mailto:freebsd-scsi@freebsd.org> List-Help: <mailto:freebsd-scsi-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-scsi>, <mailto:freebsd-scsi-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 27 Nov 2013 14:14:41 -0000 -------- Eredeti üzenet -------- Tárgy: Re: ssd for zfs Dátum: 2013-11-27 14:07 Feladó: Richard Kojedzinszky <krichy@cflinux.hu> Címzett: Tom Evans <tevans.uk@googlemail.com> Másolat: FreeBSD FS <freebsd-fs@freebsd.org> Dear FS devs, After some investigation, it turned out that when I turn write-cache off under linux, the performance drops to 100 on that OS also. But when enabled, 1400 IOPS (synchronous) can be achieved. So I would like to see the same on FreeBSD as well. Using camcontrol shows that the write cache is enabled, but I may assume that something around this is causing the performance degradation. But unfortunately I cannot step forward right now. Regards, Kojedzinszky Richard On Wed, 27 Nov 2013, Tom Evans wrote: > On Wed, Nov 27, 2013 at 8:51 AM, Richard Kojedzinszky > <krichy@cflinux.hu> wrote: >> Dear fs developers, >> >> Probably this is not the best list to report my issue, but please >> forward it >> to where it should get. >> >> I bought an SSD for my ZFS filesystem to use it as a ZIL. I've tested >> it >> under linux, and found that it can handle around 1400 random >> synchronized >> write IOPS. Then I placed it into my freebsd 9.2 box, and after >> attaching it >> as a ZIL, my zpool only performs 100 (!) write iops. I've attached it >> to an >> AHCI controller and to an LSI 1068 controller, on both it behaves the >> same. >> So I expect that something in the scsi layer is different, FreeBSD is >> handling this device slower, but actually it can handle the 1400 iops >> as >> tested under linux. >> >> Please give some advice where to go, how to debug, and how to improve >> FreeBSD's performance with this drive. >> > > The ZIL is only used for synchronous writes. The majority of writes > are asynchronous, and the ZIL is not used at all. Plus, a ZIL can only > increase iops by bundling writes - if your underlying pool is write > saturated already, then a ZIL can't help - any data written to the ZIL > has to end up on the pool. > > Test the SSD by itself under FreeBSD to rule out FreeBSD not working > correctly on the SSD (I doubt this though). > > Cheers > > Tom >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ef7e350c5edc68ba6c0a33a171c62a2a>