Date: Tue, 7 Jan 2003 15:40:43 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: phk@FreeBSD.ORG Cc: Willem Jan Withagen <wjw@withagen.nl>, current@FreeBSD.ORG Subject: Re: panic with panic: kmem_malloc(4096): kmem_map too small... Message-ID: <20030107234043.GA574@HAL9000.homeunix.com> In-Reply-To: <31595.1041930665@critter.freebsd.dk> References: <01e701c2b62b$db07ddd0$471b3dd4@dual> <31595.1041930665@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake phk@FreeBSD.ORG <phk@FreeBSD.ORG>: > >And to that fact I have a question: > > At the moment 8% of the disk is reserved. > > It being a 170Gb raid, that wastes a good 13,6Gb, which I find at lot. > > tunefs lets me bring that down to 5% = 8,5Gb without speed penalty. > > But is for this size of spare space such a large threshold really required?? > > And IF i would like to experiment, where do I look for the knop to turn?? > > Basically you don't need to reserve anything, but as you get closer to > filling the disk the time to find a free space increases rapidly and > your files get very fragmented. Trouble is: they never get defragmented > unless you copy them (or do a full dump/restore). > > I'm not sure how to nail the "right" number of % down, and I'm sure > that both Kirk and I would like to hear your numbers :-) If someone is interested in investigating this in detail, Margo Setzer et alii did a study a few years ago on aging filesystems in order to measure fragmentation. Their intent was not to measure the effect of free space on fragmentation, but their methodology could be applied for that purpose. They happen to have a graph that suggests that large file throughput drops about 20% for a filesystem that is 75% full versus a nearly empty filesystem. http://www.eecs.harvard.edu/~vino/fs-perf/papers/sigmetrics.ps.gz I don't think you'll find that it's a good idea to have a filesystem more than 90% full. At that load factor, even a uniform hash will take on average 2.5 probes to locate free space, and performance can only exponentially decrease from there. No filesystem can avoid fragmentation and perform well without a bit of breathing room. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030107234043.GA574>