From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 4 22:20:58 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F38531065670; Thu, 4 Mar 2010 22:20:57 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id 9E3AB8FC13; Thu, 4 Mar 2010 22:20:57 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 79AAD78C4B; Fri, 5 Mar 2010 07:20:49 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id 38F4A78C3B; Fri, 5 Mar 2010 07:20:49 +0900 (JST) Message-ID: <96BBFBFE5763434E8F65D8C503BABB2C@artemis> From: "Daisuke Aoyama" To: "Miroslav Lachman" <000.fbsd@quip.cz>, References: 4B5F1553.4070709@quip.cz <4B79DCA2.1070005@quip.cz> Date: Fri, 5 Mar 2010 07:20:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Scanned: ClamAV using ClamSMTP Cc: ivoras@freebsd.org Subject: Re: performance tuning of iSCSI and Dell MD3000i / gjournal problem X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 22:20:58 -0000 Hi, > And ZFS on iSCSI is the worst case with 5MB/s write performance! (I have > much better experiences with ZFS on RAIDZ pool of 4 SATA drives) I'm not sure but FreeBSD initiator does not support immediate operation. (ImmediateData=Yes) If the target supports it, the initiator can send data with the command up to the size in small one of FirstBurstLength and MaxRecvDataSegmentLength. Also the initiator can send more data up to FirstBurstLength if the target supports unsolicited operation. (InitialR2T=No) It will improve small writing performance and latency. In any case, each PDU must not exceed the target's MaxRecvDataSegmentLength. See RFC3720 page 213 and 217 for example of the sequence. http://tools.ietf.org/html/rfc3720#page-213 http://tools.ietf.org/html/rfc3720#page-217 If possible, try to increase MaxBurstLength both of the initiator and the target. It will decrease the number of R2T. Therefore, large writing is faster. Regards, Daisuke Aoyama