Date: Thu, 09 Jun 2005 09:46:03 +0100 From: Alex Zbyslaw <xfb52@dial.pipex.com> To: Frantisek Rysanek <Frantisek.Rysanek@post.cz> Cc: freebsd-questions@freebsd.org Subject: Re: Summary: 12TB GEOM stripe, newfs, then fsck: cannot alloc 768053748 bytes for blockmap Message-ID: <42A801CB.20604@dial.pipex.com> In-Reply-To: <42A7FAD3.5051.98EB5B15@localhost> References: <42A717EB.8095.9574FF2F@localhost> <42A7FAD3.5051.98EB5B15@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42A801CB.20604>