From owner-freebsd-fs@FreeBSD.ORG Wed Aug 31 11:47:26 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB188106564A for ; Wed, 31 Aug 2011 11:47:26 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 62B978FC16 for ; Wed, 31 Aug 2011 11:47:26 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p7VBlHUT070526 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 31 Aug 2011 14:47:22 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4E5E1F44.8020603@digsys.bg> Date: Wed, 31 Aug 2011 14:47:16 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110822 Thunderbird/6.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <1945418039.20110830231024@serebryakov.spb.ru> <317753422.20110830231815@serebryakov.spb.ru> <20110831004251.GA89979@icarus.home.lan> <147623060.20110831123623@serebryakov.spb.ru> <20110831101211.GA98865@icarus.home.lan> <981083303.20110831153724@serebryakov.spb.ru> In-Reply-To: <981083303.20110831153724@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Very inconsistent (read) speed on UFS2 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 11:47:26 -0000 On 31.08.11 14:37, Lev Serebryakov wrote: > >> If 5 simultaneously dds reading from the drives is very fast (way faster >> than the above) and there aren't sporadic drops in performance which >> aren't caused by writes (hence my "stop using the filesystem" comment), >> then I think we've narrowed down where the issue lies -- not the drives. > Yep. It seems to be exactly like this. > This test does not rule out drive IOPS limits. Or drive cache trashing. If you tell the drive to continuously read, or write mots of these IOs is served from/to drive cache, thus such large number of IOPS. More that the drive could handle if it has to move heads. Not saying this is the case, but things may be as simple as filling up the write cache and the drive deciding to flush it out to platters, thus reducing read rate. These are desktop drives, apparently designed for non-threaded applications. "raw" read/write speeds may be high, but higher-performing drives at much higher price points offer much more performance, even at lower "raw" read/write rates. Just spending more for smarter controller. Eliminate the writes and the drives might be worth their salt. Daniel