Date: Mon, 3 Feb 2003 21:31:33 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Ryan Dooley <ryan@third-man.com> Cc: stable@FreeBSD.ORG Subject: Re: recommendations on the newfs of a 1.0TB fs... Message-ID: <20030204053133.GA4802@HAL9000.homeunix.com> In-Reply-To: <20030204050631.GB81935@elvis.mu.org> References: <20030203194828.GA55143@elvis.mu.org> <20030204043726.GA4323@HAL9000.homeunix.com> <20030204050631.GB81935@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Ryan Dooley <ryan@third-man.com>: > > IIRC, block sizes greater than 16384 can cause significant buffer > > cache fragmentation, which can reduce I/O performance. Moreover, > > blocks that large will waste space and I/O bandwidth unless most > > of the files on the disk are very large. A smaller setting, > > e.g. the default, is probably more appropriate. > > The default wasted too much disk space (we didn't get that 1.0TB of > usable space out of it (it was more like 893GB of total usable space.) > > I do think I am wasting a bit of space. We have under 300 users with more > than 150MB of used disk. The rest of the users have between 4k and 100MB worth > of materials. Most things are web pages and images (what about 8k a page and > 16k for a good png or 64k or a good jpg?) When you say ``the default wasted too much disk space'', do you mean that when you formatted the filesystem, you had less space than you expected, or do you mean that there was less space left after you put all of your data on it? Smaller block sizes mean more space for free block bitmaps, which are allocated at filesystem creation time, but overall they are a win in terms of space because of reduced internal fragmentation. Consider what happens when you put a 10K file on the disk. Depending on whether the filesystem is optimizing for space or time, that file will take up 16K or 64K in your 64/16 filesystem, but substantially less with a 16/2 FS. So unless you are expecting most of your files to be rather large, a smaller block size may be beneficial. Note, however, that I'm not an FFS expert; other factors such as fragmentation may be relevant. > As for performance impacts, I've not seen too much in the way of that. This > is one of the fastest file systems I've got in production. The two other > "big" file systems are two raids formated with Linux's reiserfs which are > pretty darn fast when it comes to smaller files. That's good to know. I remember that Matt pointed out the buffer cache fragmentation issue some time ago, but nothing seems to have changed in terms of buffer sizes since then. Perhaps it isn't as big an issue as originally thought. (Does anyone know if it's possible to tune BKVASIZE easily, and if there are any caveats?) I would also be interested in knowing how FFS and reiserfs compare with respect to filesystem age. Does performance drop significantly after a year? If the research I've seen is right, FFS performance shouldn't drop more than 20% unless the filesystem is nearly full, and reiserfs has a cleaner... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030204053133.GA4802>