Change default dumpdir to /usr/crash?
Michael Hamburg
hamburg at fas.harvard.edu
Mon May 3 07:03:40 PDT 2004
On May 3, 2004, at 4:04 AM, Brad Knowles wrote:
> At 10:00 AM +0200 2004/05/03, Erik Trulsson wrote:
>
>> Try that calculation for a machine with 32MB RAM. You probably need a
>> minimum suggested amount of memory as well for that.
>
> Okay, then memory * 1.25, with a minimum of memory + 256MB, and a
> maximum of memory + 1GB.
Your suggested maximum seems like it would have little effect,
percentagewise. What's the real difference to someone with an 8GB
server whether their /var is _by default_ 9GB or 10GB? Presumably,
however, they will notice that their suggested minimum /var size is
larger than the suggested minimums of all the other partitions
combined, and 9GB up from 256MB.
If we increase default /var sizes, we should definitely tell the user
why somewhere in the install process, so that they can change it back
if necessary. Not everyone will want to sacrifice this amount of
memory for crashdumps, for the same reason that people turn off
INVARIANTS: the possibility of being more useful in a panic just isn't
worth the cost, be it a gig of HD space or half the CPU being eaten by
the system. There's also a privacy issue, as crashdumps may contain
passwords and the like.
Mike Hamburg
>> A base value + memory size sounds better.
>
> As you proved, you need a lower bound of usefulness. But you also
> need an upper bound, and when it comes to things like logfiles and
> other things you might want to store in /var, the larger the memory on
> the system the larger the logfiles, etc... are likely to be.
>
> Therefore, a multiplier based on memory is more likely to be useful
> than simple addition.
>
> --
> Brad Knowles, <brad.knowles at skynet.be>
>
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
> -Benjamin Franklin, Historical Review of Pennsylvania.
>
> SAGE member since 1995. See <http://www.sage.org/> for more info.
More information about the freebsd-current
mailing list