From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 22:39:36 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 208167CF; Sat, 19 Jan 2013 22:39:36 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id B8D04284; Sat, 19 Jan 2013 22:39:35 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 9so4209632iec.30 for ; Sat, 19 Jan 2013 14:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=/vhE3+5Vr5jrESFtVkL4Zdt4rq1UIQRvIBFVEh/GuIE=; b=IWrPPZ+js96KjT0ONtxJwqFzIhJLcHOxWt80Dig1gz6pnHpfdR0gzXk4vL3iaKuaFo cm53tpg6U0wD7oWrmA6o2QMChJlBE1APMNkvm3vSaiUfaub/LD9lOmeZX8k+uWhKircX niJVMH/5TxvLH69ND72e+u50ZOxPKOWcC/VZFBnYWHq5If+pVZ/AI7cbJeRMEEFtQ0Cq kQ29m1KexGUfAZ89NReU1fGBDzl39mx5AGpwzMl5HJ8AsMEX2q5Vu/ArxftBRqUZS8dW eXBzTrnxkM6sRQhJbgAXOIu2MVzkiixt2RHhlmI5xBq+w+UhPeVN2yMWuhLksoBZ9kBF d4dA== MIME-Version: 1.0 X-Received: by 10.50.196.138 with SMTP id im10mr5844794igc.83.1358635168975; Sat, 19 Jan 2013 14:39:28 -0800 (PST) Received: by 10.64.107.196 with HTTP; Sat, 19 Jan 2013 14:39:28 -0800 (PST) Date: Sat, 19 Jan 2013 14:39:28 -0800 Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: 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 22:39:36 -0000 Stefan writes: > 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). Interesting. Is there a way to tell, other than coming up with some way to actually test it, whether a particular drive waits until the data has been written to non-volatile memory (the platters in conventional disks) before sending the command completion message? I'm having thoughts of putting sensing resistors in the disk's power cable, attaching an oscilloscope, and displaying the timing of data on the data cable along with power usage from seeking.