Re: Autodefaults in disklabel on 5.0dp2 install
I recently changed the swap backoff algorithm in -current and the MFC is slated for -stable. Try this change and see if it produces better results. -Matt Index: label.c === RCS file: /home/ncvs/src/release/sysinstall/Attic/label.c,v retrieving revision 1.98.2.12 diff -u -r1.98.2.12 label.c --- label.c 3 Jul 2002 00:01:08 - 1.98.2.12 +++ label.c 4 Jul 2002 04:39:03 - @@ -1228,7 +1228,7 @@ def = SWAP_MIN_SIZE * ONE_MEG; if (def SWAP_AUTO_LIMIT_SIZE * ONE_MEG) def = SWAP_AUTO_LIMIT_SIZE * ONE_MEG; - nom = (int)(physmem / 512) / 2; + nom = (int)(physmem / 512) / 8; sz = nom + (def - nom) * perc / 100; } swap_chunk = Create_Chunk_DWIM(label_chunk_info[here].c-disk, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Autodefaults in disklabel on 5.0dp2 install
Garance A Drosihn wrote: This is something I noticed while installing 5.0-dp2. I'm not sure how much we'd want to change it. I'm installing dp2 on a 4-gig disk. I want to split that in two, with dos for the first 2 gig and freebsd in the last 2 gig. When I got to the disklabel step, I tried the Auto Defaults option to split up the freebsd partition. It picked partition sizes of: 128 meg - / 1231 meg - swap space 208 meg - /var 208 meg - /tmp 83 meg - /usr This is a machine with 768 meg of memory, but I think the install is more likely to work with a less swapspace and something more than 83 meg for /usr. I know it's tricky to come up with an algorithm which will pick decent sizes for every combination of disk and memory sizes, but perhaps it should wire in some kind of minimum size for /usr. Also, maybe something to the effect that neither /var nor /tmp should end up larger than /usr. I have not looked at the source, so maybe it's just a simple case of the swap calculation being done based on the size of the hard drive instead of the size of the freebsd partition. The default swap size calculation is done on the basis of a multiple of the physical memory size. Specifically, the physical memory may be completely consumed by kernel structures, up to the KVA size, and therefore in the case of a system dump, it can require up to the size of the physical meory, plus 64K, at a bare minimum for a successful system dump. So even if you were to reduce the swap size, you should not reduce it below 768M + 64K. 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. You should be able to take memory away from swap, even after the Auto, and give it to /usr. If you choose to give less swap than is necessary for a system dump, expect no help with problems with the system which may arise during your testing: not because no one wants to help, but because you aren't going to be able to provide sufficient information to enable them to help. If you can accept that limitation (i.e. you are trying DP2 to find problems in user space software which needs to run on it, ONLY), then fine; otherwise, you might want to consider using a bigger disk and/or removing some RAM. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Autodefaults in disklabel on 5.0dp2 install
Thus spake Garance A Drosihn [EMAIL PROTECTED]: I'm installing dp2 on a 4-gig disk. I want to split that in two, with dos for the first 2 gig and freebsd in the last 2 gig. When I got to the disklabel step, I tried the Auto Defaults option to split up the freebsd partition. It picked partition sizes of: 128 meg - / 1231 meg - swap space 208 meg - /var 208 meg - /tmp 83 meg - /usr This is a machine with 768 meg of memory, but I think the install is more likely to work with a less swapspace and something more than 83 meg for /usr. I know it's tricky to come up with an algorithm which will pick decent sizes for every combination of disk and memory sizes, but perhaps it should wire in some kind of minimum size for /usr. Also, maybe something to the effect that neither /var nor /tmp should end up larger than /usr. The algorithm could be made smarter. On the other hand, it's probably undesirable to make it so complicated that people can't fit the rules into their heads. One idea is to set up a set of linear constraints and optimize for some simple function, though even that might be overkill. At the very least, it should know when it can't find a feasible solution (``/usr can't be that small!'') and give up. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Autodefaults in disklabel on 5.0dp2 install
At 1:57 AM -0800 11/23/02, Terry Lambert wrote: Garance A Drosihn wrote: This is something I noticed while installing 5.0-dp2. I'm not sure how much we'd want to change it. The default swap size calculation is done on the basis of a multiple of the physical memory size. Specifically, the physical memory may be completely consumed by kernel structures, up to the KVA size, and therefore in the case of a system dump, it can require up to the size of the physical meory, plus 64K, at a bare minimum for a successful system dump. 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. 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. 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. 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. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Autodefaults in disklabel on 5.0dp2 install
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 justanOK 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 [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
