Date: Tue, 14 Mar 95 16:42:23 MST From: terry@cs.weber.edu (Terry Lambert) To: davidg@Root.COM Cc: roberto@blaise.ibp.fr, current@FreeBSD.org Subject: Re: MINFREE change to 8% Message-ID: <9503142342.AA09959@cs.weber.edu> In-Reply-To: <199503142318.PAA02754@corbin.Root.COM> from "David Greenman" at Mar 14, 95 03:18:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >MINFREE/2. > > > >The 5 is based on the historical default of 10%. > > > >This assumes MINFREE is a non-runtime adjustable manifest constant, right? > > > >The compare is a magic cookie to force space optimization even if the > >user has requested otherwise, since the user may run out of space very > >soon. > > Wrong. That specific comparison is to make certain that there is some > amount of hysteresis in the change from time-space & space-time optimization. > At 5%, there is only a .5% (fragmentation) gap between states. The state > change is based on filesystem fragmentation, NOT on the actual amount of > space left. OK, you're right -- it *is* a hysteresis issue. But the "5" is still a result of the historically hard-coded 10%. If you had a min and a max bounds, you'd want MINFREE/2 in any case for your hysterisis value for optimization switch threshold. For instance, if I changed it to a 3% reserve, you aren't going to ever hit a 5% +/- margin, only a 3% +/-. The reserve isn't there for a reserve, it's there for hashing. You could probably do away with the reserve entirely (but killing the ability to exercise administrative fiat in the process, it being a side effect of the reserve) by moving from a vector hash to skiplists. The 10% is the 90% fill point for least acceptable performance on the hash; anything over 90% is deemed unacceptable. The actual fall off is expotential and starts sucking at 80-85% (Knuth). When you dick with the minfree, you are in fact lowering the bottom watermark for acceptable performance for the system. It really doesn't matter that you think you are "wasting" 100M on a 1G disk; what you are paying for is a reduced average hash collision frequency. The only real difference on a 1G disk is that it become obvious that you are tying up a lot of disk based on your choice of algorithms. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503142342.AA09959>