From owner-freebsd-performance@FreeBSD.ORG Fri Sep 5 06:23:10 2003 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F0BB16A4BF; Fri, 5 Sep 2003 06:23:10 -0700 (PDT) Received: from sizone.org (mortar.sizone.org [65.126.154.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7AB843FF7; Fri, 5 Sep 2003 06:23:09 -0700 (PDT) (envelope-from dgilbert@daveg.ca) Received: by sizone.org (Postfix, from userid 66) id 37AD32FFC7; Fri, 5 Sep 2003 09:23:09 -0400 (EDT) Received: by canoe.velocet.net (Postfix, from userid 101) id 08B7D1D1C4A; Fri, 5 Sep 2003 09:23:06 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16216.36410.889440.499438@canoe.velocet.net> Date: Fri, 5 Sep 2003 09:23:06 -0400 To: "Poul-Henning Kamp" In-Reply-To: <64330.1062619621@critter.freebsd.dk> References: <3F5647F3.5080502@he.iki.fi> <64330.1062619621@critter.freebsd.dk> X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid X-Mailman-Approved-At: Mon, 08 Sep 2003 20:28:42 -0700 cc: Petri Helenius cc: Max Clark cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: Geoff Buckingham cc: Dan Nelson cc: freebsd-questions@freebsd.org Subject: Re: 20TB Storage System X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2003 13:23:10 -0000 >>>>> "Poul-Henning" == Poul-Henning Kamp writes: Poul-Henning> In message <3F5647F3.5080502@he.iki.fi>, Petri Helenius Poul-Henning> writes: >> fsck problem should be gone with less inodes and less blocks since >> if I read the code correctly, memory is consumed according to used >> inodes and blocks so having like 20000 inodes and 64k blocks should >> allow you to build 5-20T filesystem and actually fsck them. Poul-Henning> I am not sure I would advocate 64k blocks yet. Poul-Henning> I tend to stick with 32k block, 4k fragment myself. Poul-Henning> This is a problem which is in the cross-hairs for 6.x That reminds me... has anyone thought of designing the system to have more than 8 frags per block? Increasingly, for large file performance, we're pushing up the block size dramatically. This is with the assumption that large disks will contain large files. ... but I havn't seem that, myself. Large arrays that we run tend to have multiple system images (for diskless or semi-diskless operation) and many more thousands of users ... all with their usual complement of small files. It strikes me that driving the block size up (as far as 1M) and having a 256 (or so) fragments might become appropriate. We probably also need to address disks with larger block sizes soon, but that's another issue alltogether. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================