From owner-freebsd-fs@FreeBSD.ORG Tue Feb 13 09:27:18 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE65416A401 for ; Tue, 13 Feb 2007 09:27:18 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 150A113C48E for ; Tue, 13 Feb 2007 09:27:17 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (bmtuhk@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l1D9RBl5034762; Tue, 13 Feb 2007 10:27:16 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l1D9RBn9034761; Tue, 13 Feb 2007 10:27:11 +0100 (CET) (envelope-from olli) Date: Tue, 13 Feb 2007 10:27:11 +0100 (CET) Message-Id: <200702130927.l1D9RBn9034761@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG, randy@psg.com, nesimi@yahoo.com In-Reply-To: <17873.33060.746546.773210@roam.psg.com> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 13 Feb 2007 10:27:17 +0100 (CET) Cc: Subject: Re: comments on newfs raw disk ? Safe ? (7 terabyte array) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG, randy@psg.com, nesimi@yahoo.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2007 09:27:18 -0000 Randy Bush wrote: > this has been a wonderfully well-timed thread as i am about > to hack a 4tb array tomorrow afternoon. the normal spindle > is separate and partitioned to death and newfsed using the > defaults. with 2gb of ram, i figure 6gb swap just in case > two userland hogs are running at once, e.g. some hog while > background fsck is running. A bit careful here ... Background fsck had some issues, especially when the machine crashed or is otherwise reset while the background fsck is still running. It resulted in corruption that could not be repaired by fsck anymore. I don't know if all of those issues have been resolved in RELENG_6, but personally I always disable background fsck on all of my machines, just to be safe. Also note that background fsck will take longer than regular fscp, and it puts more stress on the disk, depending on what kind of applications run at the same time. > the 4tb will be used as a dump/restore target only. so i > am thinking few files, relatively big ones, little i/o and > more write than read. > > so my current plan is > > newfs -b 16384 -f 2048 -i 262144 > > i would crank up even further, but these are the largest > numbers mentioned in tuning(7). > > i will leave -m alone for now. > > does this seem reasonable? Yes, I think so. I would probably use the very same numbers in that case. I've also heard of people using 1 MB per inode (-i 1048576), but I haven't tried that high a number myself. -i 262144 works fine. In a thread some time ago, Matt Dillon commented on very high -i numbers: Matt Dillon wrote: > [...] > :> newsfeed-inn# newfs -i 67108864 /dev/twed0d > :> [stuff deleted] > :> 1048576032, 1048641568, 1048707104, 1048772640, 1048838176, 1048903712, > :> 1048969248, 1049034784, 1049100320, 1049165856, 1049231392, 1049296928, > :> 1049362464, 1049428000, 1049493536, 1049559072, 1049624608, 1049690144, > :> 1049755680, 1049821216, 1049886752, 1049952288, 1050017824, 1050083360, > :> 1050148896, 1050214432, 1050279968, 1050345504, 1050411040, 1050476576, > :> 1050542112, 1050607648, 1050673184, 1050738720, 1050804256, 1050869792, > :> 1050935328 > :> fsinit: inode value out of range (2). > :> > :> Tried larger -i parameters, same thing. > :> > :> Can't newfs figure this out before it gets to this point that something > :> isn't going to work? > :> > :> I'll try some different block/frag sizes, see if it helps. > > Specifying a byte-to-inode ratio that large is kind of silly. I > usually use something like -i 262144 -b 16384 -f 2048 on my larger > filesystems. A couple of million would also probably work, but beyond > that you aren't really saving anything, not even fsck time. I'm not > surprised that 67 million doesn't work. > > -Matt Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "[...] one observation we can make here is that Python makes an excellent pseudocoding language, with the wonderful attribute that it can actually be executed." -- Bruce Eckel