Date: Thu, 7 Jun 2007 11:41:16 -0500 From: "Rick C. Petty" <rick-freebsd@kiwi-computer.com> To: Richard Noorlandt <lists.freebsd@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: tunefs question Message-ID: <20070607164116.GA95991@keira.kiwi-computer.com> In-Reply-To: <99c92b5f0706070804p42da0881kfc866b192be60ed5@mail.gmail.com> References: <99c92b5f0706070804p42da0881kfc866b192be60ed5@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 07, 2007 at 05:04:09PM +0200, Richard Noorlandt wrote: > > While reading a bit about tunefs I noticed that UFS reserves 8% of the drive > space for the root user and the system. However, I don't really understand > what this space is actually used for. From the tunefs man page I understand > that it is primarily used to guard against fragmentation, and that's about > it. Is this the only thing that the reserved space is used for? It's used as the point where the filesystem changes over from a time-efficient algorithm to a space-efficient one. If you don't believe there's much of a difference, try writing past 100% full and witness the performance hit. There is probably a good reason why the default is 8%.. you could tune that down, but I'd be wary of doing so. > I'm building a large array for my fileserver, and it actually hurts a bit to > see that so much space is "wasted" without a very clear reason to do so. If you want to talk about wasted space, look at how many inodes are allocated on a newfs and how many you actually end up using. I have a patch to newfs which reports the amount of space "wasted" in metadata blocks.. Reducing the number of cylinder groups and number of inode blocks allocated per cylinder group can make this "wasted" space drop from 3% to 0.3%, in some circumstances. > Especially because the data on the array won't be modified very often, it > appears to be quite a lot of disk space just to prevent fragmentation. Does > anybody have some more information on this? If you don't care about fragmentation or speed, go ahead and fill up past 100%. If you need non-root writable access, go ahead and tune the 8% to a smaller number. Be warned-- you will likely be sacrificing speed just to fill that extra space. If your modifications are rare, you might be able to run some sort of offline defragmentation program. I was working on such a program at one point. Also, I wouldn't call this "a lot of disk space". Disks are cheap: http://www.newegg.com/Product/Product.asp?Item=N82E16822136073 $115 for 500GB drives. If you need more space, buy more disks. You may wish to consider the opportunity cost of the time you spend tweaking file systems to use that extra couple percent space versus the cost of additional storage. > And while I'm at it: what is the effect of the expected average file size > option? What are the benefits and dangers of tweaking it? From the FreeBSD > handbook I understand that the FS actually optimizes itself as time passes, > but that's about all that's said about it. Don't tweak average file size (or it's related avg. files per directory setting)! There are some reported bugs in UFS regarding the computation (integer overflow) that is performed on the average file size parameter. I first noticed this when tweaking it on a new filesystem that I knew the average filesize was high (ISO images) and my kernel panicked on the first write attempt. Subsequent reboots panicked during fsck. I've looked into patching the necessary UFS code but never got around to a complete fix. Instead, just modify the inode density (-i option to newfs) which means pretty much the same thing and doesn't have the bug. Tweaking this parameter only affects newfs.. actually it's used in the computation for number of inodes per cylinder group and indirectly affects total number of cylinder groups-- newfs uses a loop to increase number of cyl groups until the free block bitmap can fit into a single filesystem block (which defaults to 16384 bytes). Tweaking this option, I've been able to reduce the space allocated to metadata by tenfold. I recommend first running newfs with the -N option to print out the total number of allocated inodes. Make sure you won't go over this number (running out of inodes can be an aggravating problem), and if you're satisfied rerun newfs for real. If you're tweaking -i, you may wish to tweak the block size as well.. but make sure the fragment size is precisely 1/8 of the block size or all bets go out the window (particularly: performance hits). Aside from those three settings, I don't mess with newfs much because there is little to gain. If you know the precise files (i.e. total number of files + number of directories --> number of inodes, average filesize --> inode density), this helps you speeze more space without sacrificing anything. I do this often when transitioning a read-write filesystem to a read-only / archive filesystem. Set the time/space setting to space, set the reserved free space from 8% to 1%, fill up the filesystem, unmount and set it back to time & 8%, and mount it read-only for the remainder of its lifetime. This requires a total of five extra minutes of your admin time. Good luck, -- Rick C. Petty
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070607164116.GA95991>