From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 22:32:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AFF0106573B; Mon, 19 Dec 2011 22:32:12 +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 007A78FC0C; Mon, 19 Dec 2011 22:32:11 +0000 (UTC) Received: from digsys226-136.pip.digsys.bg (digsys226-136.pip.digsys.bg [193.68.136.226]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id pBJMVsNV022033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Dec 2011 00:32:01 +0200 (EET) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Daniel Kalchev In-Reply-To: <20111219215317.GL53453@dan.emsphone.com> Date: Tue, 20 Dec 2011 00:31:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EEF488E.1030904@freebsd.org> <20111219162220.GK53453@dan.emsphone.com> <4EEFA05E.7090507@freebsd.org> <20111219215317.GL53453@dan.emsphone.com> To: Dan Nelson X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD Current Subject: Re: Uneven load on drives in ZFS RAIDZ1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:32:12 -0000 On Dec 19, 2011, at 11:53 PM, Dan Nelson wrote: >=20 > Since it looks like the algorithm ends up creating two half-cold = parity > disks instead of one cold disk, I bet a 3-disk RAIDZ would exhibit = even > worse balancing, and a 5-disk set would be more even. There were some experiments a year or two ago with different number of = disks in raidz and the results suggested that certain number of disks = had better performance, contrary to theory that writes should be evenly = distributed. Worse, this is in the official theory of how raidz = operates=85 Perhaps the code can be fixed to spread the writes to all devices in = raidz, but compatibility issues need to be considered. Perhaps DDT is stored in the 'worst case' write size, because it clearly = exhibits such poor distribution. Daniel=