Date: Sat, 23 Nov 2002 03:09:26 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Garance A Drosihn <drosih@rpi.edu> Cc: current@FreeBSD.org Subject: Re: "A"utodefaults in disklabel on 5.0dp2 install Message-ID: <3DDF61E6.8CB4BD28@mindspring.com> References: <p05200f01ba04e268e97b@[128.113.24.47]> <3DDF5106.7469FBA@mindspring.com> <p05200f02ba050a193724@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
Garance A Drosihn wrote: > Hmm. I hadn't really thought much about the specifics of what > is needed. I was just wondering if we might want to think about > the "auto size" algorithm a bit more. The value, by default is 2 * `sysctl hw.physmem`. This is kind of ugly, because it doesn't include the space for the kernel itself. There isn't a sysctl variable with the actual size of the real physical RAM, without the kernel and page table space subtracted out of it, unfortunately (I tried to get a patch in on this a year ago, last June). > >So even if you were to reduce the swap size, you should not reduce > >it below 768M + 64K. > > Well, I can see that the "auto default" partition mechanism should > probably take that into account too. I'm just saying that the > current algorithm gives the user (any generic user, not me specifically) > a useless result. It would be nice if it came up with more usable sizes. The 2 * physical memory *is* a useful size, for most cases. The base assumption here is that you installed that much memory for a reason, and you intend to use it. That yields a proper swap size. It also permits you to (almost) double the amount of physical RAM installed on the machine, and still successfully crash dump, so it gives you room to upgrade your hardware. > >You will, of course, agree that a prerelease named "DP2" should > >have the ability to successfully system dump, as that is one of > >the primary reasons it's being handed out: to catch problems, and > >to provide detailed bug reports about them, sufficient to correct > >them before the official release. > > Well, I mentioned this now with an eye towards 5.0-release, although > I realize my original message didn't indicate that. This same issue > comes up when installing recent releases from 4-stable. My point is > that the resulting partition sizes (in this case) are unusable. There > is no point in worrying about the ability to save a system dump on a > system where the initial install has pretty close to zero chance of > succeeding. It's very difficult to get disks that small these days, without partitioning for multiboot, or going to a back room somewhere, and blowing dust off a box. 8-). I think the most common place this would happen is someone "trying out FreeBSD". That makes it an important problem for -RELEASE, I think. Not knowing what people intend to install up front, it's hard to know how much space is ncessary for various files. I think someone needs to come up with "minimum ratios" and "hog" partitions -- like "swap" -- that can be stolen from in order to get a running system (it should also spit out an alarming message with justan"OK" button (to steal from Windows 8-)) about not being able to support crash dumps. I don't think anyone would object to patches; the code you want to hack will be in /usr/src/usr.sbin/sysinstall/label.c. > Let me repeat that I'm not sure how much we'd want to change it. I > just wanted to point out how the current algorithm behaves when given > this particular combination of disk and memory sizes. Spitting out "Insufficient resources" is a sure way to scare someone off. 8-(. -- Terry 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?3DDF61E6.8CB4BD28>