From owner-freebsd-questions@FreeBSD.ORG Thu Jun 9 08:46:08 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E53916A41C for ; Thu, 9 Jun 2005 08:46:08 +0000 (GMT) (envelope-from xfb52@dial.pipex.com) Received: from smtp-out2.blueyonder.co.uk (smtp-out2.blueyonder.co.uk [195.188.213.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9267E43D1F for ; Thu, 9 Jun 2005 08:46:06 +0000 (GMT) (envelope-from xfb52@dial.pipex.com) Received: from [82.41.37.55] ([82.41.37.55]) by smtp-out2.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Thu, 9 Jun 2005 09:46:45 +0100 Message-ID: <42A801CB.20604@dial.pipex.com> Date: Thu, 09 Jun 2005 09:46:03 +0100 From: Alex Zbyslaw User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7.8) Gecko/20050530 X-Accept-Language: en, en-us, pl MIME-Version: 1.0 To: Frantisek Rysanek References: <42A717EB.8095.9574FF2F@localhost> <42A7FAD3.5051.98EB5B15@localhost> In-Reply-To: <42A7FAD3.5051.98EB5B15@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2005 08:46:45.0820 (UTC) FILETIME=[C45A27C0:01C56CCF] Cc: freebsd-questions@freebsd.org Subject: Re: Summary: 12TB GEOM stripe, newfs, then fsck: cannot alloc 768053748 bytes for blockmap X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2005 08:46:08 -0000 Frantisek Rysanek wrote: >Thanks a lot to Mr. Zbyslaw. > > You're welcome. >A local friend has suggested to increase the block size to >newfs, or something along those lines - essentially to >decrease the FS overhead and the size of the "blockmap". >I haven't tried that but I guess it sounds reasonable >- may make sense on machines where you just can't get >enough RAM or are not willing to grant it all to a single >process. > > It ought also make sense if you are serving up *large* files (didn't you say video/audio?). I'm planning to do some tests at some point to see what difference different block/fragment sizes make to performance, but haven't found the time yet. I don't have anything on your scale (23Gb of document database pales into insignificance against 12Tb :-) ) but I haven't found any specific numbers anywhere. If you're interested, check out the -b and -f options to newfs. The defaults are 16k/2k. Decreasing the number of inodes would definitely make sense (see -i). The -N option ought to show you what would happen without actually doing anything. --Alex