From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 15:27:54 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8707075C for ; Sat, 19 Jan 2013 15:27:54 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm22-vm7.bullet.mail.ird.yahoo.com (nm22-vm7.bullet.mail.ird.yahoo.com [212.82.109.226]) by mx1.freebsd.org (Postfix) with ESMTP id BF326A6 for ; Sat, 19 Jan 2013 15:27:53 +0000 (UTC) Received: from [212.82.105.244] by nm22.bullet.mail.ird.yahoo.com with NNFMP; 19 Jan 2013 15:27:52 -0000 Received: from [217.146.188.172] by tm16.bullet.mail.ird.yahoo.com with NNFMP; 19 Jan 2013 15:27:52 -0000 Received: from [127.0.0.1] by smtp140.mail.ird.yahoo.com with NNFMP; 19 Jan 2013 15:27:52 -0000 X-Yahoo-Newman-Id: 276545.61908.bm@smtp140.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8TgKlNUVM1kP1rLbGWXE6iah7DTlgi3M1ivVIkCi3t2F8S. gQSxEWwK_T9Wauvp33BHiZZP3QA.q1cv15Nt8ca1VG0j8cR9Lb2RAby5zknC yDPX.gwgCtyUdjtkEzsL7D7KybAmcz0lFvldlDRsCbOpSHqOWkhxevB68aE1 bQ_zIvyiGgb7OE.q1Udb4yU_KQ03zvbrkbbBLNGIL5I7QLGz.KSQBIxqlalG cJVklcIx9oAKmrooq1AZCFbGJCJE9RGN9rrLZnLUIQVU7270nHOaVtjiqzkX hzQ.9tll7URh1iILafhK4DaoQZciTvicxyyqkQqw4lGpgzG_LZTgs77_6jiR 9LkXBIPm.igrqF40UdjOcXQMKge2ymaSBhdjvx.jyUxcQJtJhdWoY9ClB_an 3K5uFrWdiIUFkWIJfcWOhRpBb7Uifkg7Lnu_4PpEcMGi6wSl.jQ-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.26] (se@87.158.17.243 with plain) by smtp140.mail.ird.yahoo.com with SMTP; 19 Jan 2013 07:27:52 -0800 PST Message-ID: <50FABB71.6050406@freebsd.org> Date: Sat, 19 Jan 2013 16:27:45 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Karim Fodil-Lemelin Subject: Re: IBM blade server abysmal disk write performances References: <6C0B86E6-195C-4D35-AE40-3D2F9F6D28FB@yahoo.com> <1358544287.32417.251.camel@revolution.hippie.lan> <50F9CFEB.5060302@feral.com> <50F9DB9A.9050303@gmail.com> In-Reply-To: <50F9DB9A.9050303@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, gibbs@FreeBSD.org, scottl@FreeBSD.org, mjacob@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 15:27:54 -0000 Am 19.01.2013 00:32, schrieb Karim Fodil-Lemelin: > * Although no one has reported problems with the 2 gig > * version of the DCAS drive, the assumption is that it > * has the same problems as the 4 gig version. Therefore > * this quirk entries disables tagged queueing for all > * DCAS drives. > */ > { T_DIRECT, SIP_MEDIA_FIXED, "IBM", "DCAS*", "*" }, > /*quirks*/0, /*mintags*/0, /*maxtags*/0 > > So I looked at the kern/10398 pr and got some feeling of 'deja vu' > although the original problem was on FreeBSD 3.1 so its most likely not > that but I though I would mention it. The issue described is awfully > familiar. Basically the SAS drive (scsi back then) is slow on writes but > fast on reads with dd. Could be a coincidence or a ghost from the past > who knows... I remember those drives from some 20 years ago. Before that time, SCSI and IDE drives were independently developed and SCSI drives offered way better performance and reliability. But at about this time there were SCSI and IDE drives that differed only in their interface electronics. And from that time I and models I remember several SCSI quirks in IBM drives (DCAS and DORS), often with regard to tagged commands. I seem to remember, that drives of that time required the write cache to be enabled to get any speed-up from tagged commands. This was no risk with SCSI drives, since the cache did not make the drives lye about command completion (i.e. the status for the write was only returned when the cached data had been written to disk, independently of the write cache enable). Regards, STefan