From owner-freebsd-fs@FreeBSD.ORG Wed Aug 31 12:49:38 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 6ED3F106566B; Wed, 31 Aug 2011 12:49:38 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9378FC12; Wed, 31 Aug 2011 12:49:38 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:6407:f3f9:7d93:d34c]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 6E1074AC31; Wed, 31 Aug 2011 16:49:36 +0400 (MSD) Date: Wed, 31 Aug 2011 16:49:33 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <809344970.20110831164933@serebryakov.spb.ru> To: Jeremy Chadwick In-Reply-To: <20110831101211.GA98865@icarus.home.lan> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Lev Serebryakov Subject: Re: Very inconsistent (read) speed on UFS2 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 12:49:38 -0000 Hello, Jeremy. You wrote 31 =E0=E2=E3=F3=F1=F2=E0 2011 =E3., 14:12:11: > The dd method I describe should absolutely not induce writes, hence my > recommendation. If writes are seen during the dd's, then either the > filesystem is mounted and FreeBSD is doing something "interesting" on a > filesystem or vfs level, or your system is actually an izbushka..... I've eliminate writes. It was RAID5 metadata updates due to very paranoid check for "new metadata". It doesn't hurt in terms of dtaa safety, but not in terms of speed. Ok, now results are MUCH MORE consistent, and is about 50% of theoretical maximum on average. Looks good. SLOWEST (by Average) files: Name Min/Avg/Max StdDev r007f05.nef 205/230/242 MiB/s 12 r008f06.nef 215/234/254 MiB/s 14 r018f10.nef 218/235/258 MiB/s 13 r013f09.nef 230/243/256 MiB/s 9 r013f11.nef 236/243/249 MiB/s 4 r008f10.nef 238/243/249 MiB/s 3 r015f04.nef 220/244/265 MiB/s 17 r011f04.nef 240/245/256 MiB/s 5 r015f05.nef 221/248/286 MiB/s 24 r008f09.nef 231/250/266 MiB/s 11 MOST UNSTABLE files: Name Min/Avg/Max StdDev r008f12.nef 291/327/377 MiB/s 38 r021f06.nef 307/382/404 MiB/s 37 r021f02.nef 253/295/346 MiB/s 34 r013f08.nef 264/329/352 MiB/s 33 r012f05.nef 298/354/398 MiB/s 32 r020f05.nef 305/357/388 MiB/s 30 r020f03.nef 292/316/376 MiB/s 30 r022f06.nef 284/319/371 MiB/s 30 r010f12.nef 303/346/377 MiB/s 29 r013f06.nef 285/329/365 MiB/s 29 --=20 // Black Lion AKA Lev Serebryakov