Date: Tue, 13 Feb 2007 10:27:11 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-fs@FreeBSD.ORG, randy@psg.com, nesimi@yahoo.com Subject: Re: comments on newfs raw disk ? Safe ? (7 terabyte array) Message-ID: <200702130927.l1D9RBn9034761@lurza.secnetix.de> In-Reply-To: <17873.33060.746546.773210@roam.psg.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200702130927.l1D9RBn9034761>