From owner-freebsd-performance@FreeBSD.ORG Fri Mar 2 12:59:58 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 330BC16A5B4 for ; Fri, 2 Mar 2007 12:59:58 +0000 (UTC) (envelope-from tec@mega.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id AAE8513C4A7 for ; Fri, 2 Mar 2007 12:59:57 +0000 (UTC) (envelope-from tec@mega.net.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l22BgLeS074567 for ; Fri, 2 Mar 2007 08:42:21 -0300 (BRT) (envelope-from tec@mega.net.br) From: NOC Meganet Organization: Prowip Telecom Ltda To: freebsd-performance@freebsd.org Date: Fri, 2 Mar 2007 08:42:22 -0300 User-Agent: KMail/1.9.5 References: <45E7F09B.7070005@zedat.fu-berlin.de> <00c401c75caf$89ee3370$3c01a8c0@coolf89ea26645> In-Reply-To: <00c401c75caf$89ee3370$3c01a8c0@coolf89ea26645> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703020842.23082.tec@mega.net.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: (S)ATA performance in FBSD 6.2/7.0 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 12:59:58 -0000 On Friday 02 March 2007 06:45, Ted Mittelstaedt wrote: > blah blah blah deleted > idem ;) > > Before digging into this problem deeper with benchmarks, could anyone > > explain why FreeBSD reaches this 33 MB/s limit (sounds like UDMA 33 > > man mount > > read section on "async" > > linux by default mounts async > > freebsd by default mounts sync > > you can change FBSD to async > > then watch your fs scramble during a power failure > > no big deal, it's only your data. > big deal however is if it is a FBSD flaw or not since you do already compare I like to add that this scramble thing does not happen on Linux as far as I remember but I must admit I never tested it, I only observed it after powerfailure on some redhat WSs I have but anyway cp or dd probably is not a performance measurement tool at all and a software should take proper care of disk i/o whatever fs it is installed on I do not know if it makes any sense discussing cp or dd performance HM A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br