Re: 8.0-RELEASE -> -STABLE and size of /
On Friday 05 February 2010 9:00:51 am Oliver Fromme wrote: > Randi Harper wrote: > > Marian Hettwer wrote: > > > +1 vote for making / bigger. > > > At least a size where a make installkernel runs through. > > > > This is going to happen. It's been on my to-do list for a while, as I > > find it increasingly annoying. The default sizes of all mount points > > need to be tweaked a bit. Be patient, there will be some new changes > > going into sysinstall very soon. > > Revisiting sysinstall's default partition sizes is certainly > a good idea. > > However, I think it makes a lot of sense to *not* install > symbol files in /boot/kernel by default. I can't think of > a good reason why they need to be there by default, and > they're what causes the space problems for the root FS in > the first place. > > Please change the default. It makes debugging kernel crashes for simpler and easier. For example, with the kernel symbols installed, the crashinfo(8) script can generate useful information after a crash on an out-of-the-box system. -- John Baldwin ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
Randi Harper wrote: > Marian Hettwer wrote: > > +1 vote for making / bigger. > > At least a size where a make installkernel runs through. > > This is going to happen. It's been on my to-do list for a while, as I > find it increasingly annoying. The default sizes of all mount points > need to be tweaked a bit. Be patient, there will be some new changes > going into sysinstall very soon. Revisiting sysinstall's default partition sizes is certainly a good idea. However, I think it makes a lot of sense to *not* install symbol files in /boot/kernel by default. I can't think of a good reason why they need to be there by default, and they're what causes the space problems for the root FS in the first place. Please change the default. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
Hi Randi, On 02/03/10 02:43, Randi Harper wrote: This is going to happen. It's been on my to-do list for a while, as I find it increasingly annoying. The default sizes of all mount points need to be tweaked a bit. Be patient, there will be some new changes going into sysinstall very soon. Great! Thank you! my next machine I again installed ZFS only, so there I didn't run into the topic :-) - Olli ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Fri, Jan 22, 2010 at 8:27 AM, Marian Hettwer wrote: > Hi All, > > On Fri, 22 Jan 2010 17:21:56 +0100, Oliver Brandmueller > wrote: >> Hi, >> >> I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default >> 512M. First step after setup was to csup to RELENG_8 and buildkernel and >> buildworld (no custom kernel, no make.conf). >> >> Instaling the new kernel failed, since /boot/kernel/ is already well >> over 230 MBytes in size. moving that to kernel.old and writing a new one >> with about the same size fails due to no space left on device. >> >> This is not a question; I do know how to get around this and how to >> configure custom kernels so they are a fragment of that size afterwards. >> However, I think this is a clear POLA violation. So, either GENERIC with >> less debugging information (symbols and stuff), which makes debugging >> harder or setting a higher default for / would be options, if not anyone >> else has better ideas. >> > +1 vote for making / bigger. > At least a size where a make installkernel runs through. > > I like FreeBSD because it honors POLA. > And as Oliver stated, this is a clear POLA violation. > > Cheers, > Marian > > ___ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[email protected]" > This is going to happen. It's been on my to-do list for a while, as I find it increasingly annoying. The default sizes of all mount points need to be tweaked a bit. Be patient, there will be some new changes going into sysinstall very soon. -- randi ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
on 29/01/2010 16:33 Jeremy Chadwick said the following: > > The *.symbols files I have for the kernel are installed in /boot/kernel. > I'm referring to "stuff" in /usr/obj which appears to be required to > debug a crash (vmcore). What I'm describing is even mentioned in the > FreeBSD Developers Handbook: > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html > > Note the first two steps: > > 1:# cd /usr/obj/usr/src/sys/KERNCONF > 2:# kgdb kernel.debug /var/crash/vmcore.0 No, that information is outdated. The *.symbols files in /boot/kernel are required, "stuff in /usr/obj" is not. You start debugging by kgdb /boot/kernel/kernel /var/crash/vmcore.0 or whatever are the proper paths. BTW, this section is also obsolete: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-kld.html Modules/their symbols are loaded automatically in the recent versions of FreeBSD. -- Andriy Gapon ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Fri, Jan 29, 2010 at 04:25:27PM +0200, Andriy Gapon wrote: > on 29/01/2010 15:40 Jeremy Chadwick said the following: > > On Fri, Jan 29, 2010 at 10:29:51PM +1030, Daniel O'Connor wrote: > >> On Fri, 29 Jan 2010, Ruben de Groot wrote: > I don't think you need them unless remote debugging and in that > case you are multiuser (I would have thought anyway). > > If they went into /usr then /boot could remain slim. > >>> But what if you have /usr on a gmirror, glabel, zfs filesystem or any > >>> other device that is not compiled in your kernel? Sure you can build > >>> a custom kernel, but I would expect a lot of questions, frustrations > >>> and footshooting from such a change. > >>> > >>> I think increasing / (again) would be the least painfull. > >> You don't need debug symbols to boot a kernel, you only need them when > >> debugging. > > > > Somewhat related: can someone explain why debugging a crash dump of a > > kernel which contains "makeoptions DEBUG=-g" requires and relies on > > stuff in /usr/obj? > > So do remove or not install *.symbols files? > That would explain it. > I keep those files and my debugging doesn't depend on /usr/obj. > > > Meaning: if I build kernel/world, install kernel/world, and then rm -fr > > /usr/obj/*, I won't be able to reliably debug a crash dump after the > > system restarts. I believe I can get a stack trace, but there's nothing > > else that can be ascertained (bt full is basically worthless). > > > > I've seen kernel crash dumps from people here on the list[1] which > > contain way more detail than any of mine do[2]. > > > > Off-topic: I've noticed that /usr/obj is created as part of the OS > > installation with perms 0755. I've always thought there might be > > security implications by that, so usually end up setting it to 0700 or > > possibly 0750 (still root:wheel). > > > > [1]: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054269.html > > [2]: > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052256.html The *.symbols files I have for the kernel are installed in /boot/kernel. I'm referring to "stuff" in /usr/obj which appears to be required to debug a crash (vmcore). What I'm describing is even mentioned in the FreeBSD Developers Handbook: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html Note the first two steps: 1:# cd /usr/obj/usr/src/sys/KERNCONF 2:# kgdb kernel.debug /var/crash/vmcore.0 -- | Jeremy Chadwick [email protected] | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
on 29/01/2010 15:40 Jeremy Chadwick said the following: > On Fri, Jan 29, 2010 at 10:29:51PM +1030, Daniel O'Connor wrote: >> On Fri, 29 Jan 2010, Ruben de Groot wrote: I don't think you need them unless remote debugging and in that case you are multiuser (I would have thought anyway). If they went into /usr then /boot could remain slim. >>> But what if you have /usr on a gmirror, glabel, zfs filesystem or any >>> other device that is not compiled in your kernel? Sure you can build >>> a custom kernel, but I would expect a lot of questions, frustrations >>> and footshooting from such a change. >>> >>> I think increasing / (again) would be the least painfull. >> You don't need debug symbols to boot a kernel, you only need them when >> debugging. > > Somewhat related: can someone explain why debugging a crash dump of a > kernel which contains "makeoptions DEBUG=-g" requires and relies on > stuff in /usr/obj? So do remove or not install *.symbols files? That would explain it. I keep those files and my debugging doesn't depend on /usr/obj. > Meaning: if I build kernel/world, install kernel/world, and then rm -fr > /usr/obj/*, I won't be able to reliably debug a crash dump after the > system restarts. I believe I can get a stack trace, but there's nothing > else that can be ascertained (bt full is basically worthless). > > I've seen kernel crash dumps from people here on the list[1] which > contain way more detail than any of mine do[2]. > > Off-topic: I've noticed that /usr/obj is created as part of the OS > installation with perms 0755. I've always thought there might be > security implications by that, so usually end up setting it to 0700 or > possibly 0750 (still root:wheel). > > [1]: > http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054269.html > [2]: > http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052256.html > -- Andriy Gapon ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Fri, Jan 29, 2010 at 10:29:51PM +1030, Daniel O'Connor wrote: > On Fri, 29 Jan 2010, Ruben de Groot wrote: > > > I don't think you need them unless remote debugging and in that > > > case you are multiuser (I would have thought anyway). > > > > > > If they went into /usr then /boot could remain slim. > > > > But what if you have /usr on a gmirror, glabel, zfs filesystem or any > > other device that is not compiled in your kernel? Sure you can build > > a custom kernel, but I would expect a lot of questions, frustrations > > and footshooting from such a change. > > > > I think increasing / (again) would be the least painfull. > > You don't need debug symbols to boot a kernel, you only need them when > debugging. Somewhat related: can someone explain why debugging a crash dump of a kernel which contains "makeoptions DEBUG=-g" requires and relies on stuff in /usr/obj? Meaning: if I build kernel/world, install kernel/world, and then rm -fr /usr/obj/*, I won't be able to reliably debug a crash dump after the system restarts. I believe I can get a stack trace, but there's nothing else that can be ascertained (bt full is basically worthless). I've seen kernel crash dumps from people here on the list[1] which contain way more detail than any of mine do[2]. Off-topic: I've noticed that /usr/obj is created as part of the OS installation with perms 0755. I've always thought there might be security implications by that, so usually end up setting it to 0700 or possibly 0750 (still root:wheel). [1]: http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054269.html [2]: http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052256.html -- | Jeremy Chadwick [email protected] | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Fri, 29 Jan 2010, Ruben de Groot wrote: > > I don't think you need them unless remote debugging and in that > > case you are multiuser (I would have thought anyway). > > > > If they went into /usr then /boot could remain slim. > > But what if you have /usr on a gmirror, glabel, zfs filesystem or any > other device that is not compiled in your kernel? Sure you can build > a custom kernel, but I would expect a lot of questions, frustrations > and footshooting from such a change. > > I think increasing / (again) would be the least painfull. You don't need debug symbols to boot a kernel, you only need them when debugging. Since the debugging either happens after the fact (analysing a core) or remotely (and the remote system would have /usr mounted) I don't see that they need to go into /boot. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: 8.0-RELEASE -> -STABLE and size of /
On Sat, Jan 23, 2010 at 10:43:49PM +1030, Daniel O'Connor typed: > On Sat, 23 Jan 2010, Ruben de Groot wrote: > > On Sat, Jan 23, 2010 at 01:23:28AM +, Adrian Wontroba typed: > > > I concur that the 235 MB size of an amd64 8.0 kernel is a bit of a > > > surprise. An i386 kernel is a mere 135 MB. IMO increasing the > > > sysinstall default root slice size for at least amd64 would be a > > > good thing. > > > > To be a little more precise: it's not the >kernel< that is so big. > > It's all the (mostly not needed) modules and symbol files that fill > > up / > > Maybe they could be put somewhere else.. > > I don't think you need them unless remote debugging and in that case you > are multiuser (I would have thought anyway). > > If they went into /usr then /boot could remain slim. But what if you have /usr on a gmirror, glabel, zfs filesystem or any other device that is not compiled in your kernel? Sure you can build a custom kernel, but I would expect a lot of questions, frustrations and footshooting from such a change. I think increasing / (again) would be the least painfull. Ruben ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
Hi, On Sat, Jan 23, 2010 at 04:20:54PM -0800, Kevin Oberman wrote: > Also, at the start of this thread, the OP said that he did a buildkernel > and a buildworld. This is broken and may produce a non-bootable > kernel. Always buildworld and then buildkernel so that the new toolchain > is used to build the kernel. (This also has nothing to do with the > original issue of the amount of space in the root partition being too > small for amd64 systems, but I am hoping to avoid future issues.) I did both in the right order (first buildworld, then buildkernel). The kernel was OK and bootable. I hd no problem, just experienced something that in my opinion violates POLA. buildworld + buildkernel + installkernel should not produce an error for a fresh default installation. I think we all agreee on that. You can try this easily with an amd64 8.0-RELEASE. - Oliver -- | Oliver Brandmueller http://sysadm.in/ [email protected] | |Ich bin das Internet. Sowahr ich Gott helfe. | ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Sat, 23 Jan 2010 20:41:59 -0600 Larry Rosenman wrote: > > add the following to /etc/make.conf: > INSTALL_NODEBUG=yes This is useful. Thanks! -- Regards, Torfinn Ingolfsen ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
Miroslav Lachman <[email protected]> wrote: > Why you are suggesting /var >= 2*RAM? Is it just for saving crash dumps > or anything else? And why so big /tmp? I am running servers with smaller > sizes for years without any problem. Me too. I usually set up a small memory disk for /tmp. I never experienced any serious problems with that. The machine I'm typing this on right now has this line in /etc/fstab: md /tmp mfs rw,nosuid,-s200m,async 0 0 Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java" ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Fri, 22 Jan 2010, Oliver Brandmueller wrote: Hi, I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default 512M. First step after setup was to csup to RELENG_8 and buildkernel and buildworld (no custom kernel, no make.conf). Instaling the new kernel failed, since /boot/kernel/ is already well over 230 MBytes in size. moving that to kernel.old and writing a new one with about the same size fails due to no space left on device. Replying to the first post in the thread. One first thing to help people to avoid problems with future upgrades could be to just make / 1G: http://people.freebsd.org/~bz/20100124-03-sysinstall-root-1g.diff Another entirely untested patch would compress the symbol files: http://people.freebsd.org/~bz/20100124-04-kernel-compress-symbols.diff It would be interesting to see if (a) they work and (b) how much the latter would safe. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Sat, January 23, 2010 8:35 pm, Torfinn Ingolfsen wrote: > On Sat, 23 Jan 2010 16:20:54 -0800 > Kevin Oberman wrote: > >> Just for the record and to avoid further confusion, building a kernel >> with debug symbols does not take any more space in root. Another copy of >> the kernel is built but not installed into /kernel. The copy of the >> kernel >> in /kernel is always symbol-less. > > Perhaps my question should be changed to: > how do I configure the "make world" procedure so that no files ending > in '*symbol' get installed in /boot/kernel? add the following to /etc/make.conf: INSTALL_NODEBUG=yes > -- > Regards, > Torfinn Ingolfsen > > ___ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[email protected]" > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: [email protected] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Sat, 23 Jan 2010 16:20:54 -0800 Kevin Oberman wrote: > Just for the record and to avoid further confusion, building a kernel > with debug symbols does not take any more space in root. Another copy of > the kernel is built but not installed into /kernel. The copy of the kernel > in /kernel is always symbol-less. Perhaps my question should be changed to: how do I configure the "make world" procedure so that no files ending in '*symbol' get installed in /boot/kernel? -- Regards, Torfinn Ingolfsen ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
> From: Steven Friedrich > Date: Fri, 22 Jan 2010 22:20:30 -0500 > Sender: [email protected] > > On Friday 22 January 2010 06:32:02 pm Oliver Brandmueller wrote: > > Hi, > > > > On Fri, Jan 22, 2010 at 03:56:31PM -0500, Steven Friedrich wrote: > > > in your /etc/make.conf, do you have a line like: > > > makeoptions DEBUG=-g > > > if so, comment it out. > > > > The GENEREIC kernel by default has the following config: > > > > makeoptions DEBUG=-g# Build kernel with gdb(1) debug > > symbols > > > > You don't need anything special in your make.conf > > > > In fact having the debug symbols is useful in many cases. So raising the > > default size for the / partition might be the better option (OK, doesn't > > help for already installed systems of course). > > > > - Oliver > > > I'm sorry. My response to him should have been more precise. > I was trying to clue him in on how to build a non-debug kernel, but my > answer was in fact wrong. > I said he may have a line in make.conf, but that was a mistake. I > pulled the line from a kernel config file. > If he wants to build a kernel with no symbols, as he stated he does, > he needs to comment out the line and build a kernel. Could buildworld > and installworld, too. > But he and I went off topic. I should have changed the subject line to > start a new thread to discuss building without symbols. He was > complaining that it wasn't in the FAQ or the handbook. It's in > GENERIC, which is required reading if you're ever going to build > custom kernels. > > As for the main topic, I have been making 4GB root partitions for some time. > Our disk requirements have been soaring over the last decade, while cost per > MB have plummeted. I don't want to have to guess what sizes each partition > should be. Just for the record and to avoid further confusion, building a kernel with debug symbols does not take any more space in root. Another copy of the kernel is built but not installed into /kernel. The copy of the kernel in /kernel is always symbol-less. Also, at the start of this thread, the OP said that he did a buildkernel and a buildworld. This is broken and may produce a non-bootable kernel. Always buildworld and then buildkernel so that the new toolchain is used to build the kernel. (This also has nothing to do with the original issue of the amount of space in the root partition being too small for amd64 systems, but I am hoping to avoid future issues.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [email protected] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Sat, Jan 23, 2010 at 12:21:48PM -0800, Jeremy Chadwick wrote: > On Sat, Jan 23, 2010 at 09:04:57PM +0100, Miroslav Lachman wrote: > > Jeremy Chadwick wrote: ... > > And why so big /tmp? I am running servers with smaller sizes for years > > without any problem. > > My recommendation above doesn't imply those who don't use it will have > problems -- each environment/system is different. > > That said, it's amazing how much software out there blindly uses /tmp. > Last year I ran into this situation: an older server (1GB /tmp) started > behaving oddly due to /tmp filling. A user of the system was using lynx > to download some large files (an ISO image and something else, I forget > what). lynx saves data its downloading to /tmp, and once it completes, > the user is prompted where to save the data (CWD being the default). Another example: the stock /usr/bin/sort uses /tmp for its temporary storage when it needs to start using disk. You can redirect that via -T if you think ahead and realize that it's going to be a problem, but if you are just whipping up a quick shell script and later happen to run it on much bigger inputs than you were expecting you can run out of space on /. (Yes, that happened to me fairly recently on several systems, when some log files weren't being rotated on schedule.) An alternative solution is to symlink /tmp to /var/tmp, which I've done on many systems, assuming that nothing in the /etc/rc sequence will need /tmp before filesystems are mounted. (I suppose putting it on its own filesystem also assumes that.) In general, I think you've got a good idea and I plan to start adopting that in the future. -- Clifton -- Clifton Royston -- [email protected] / [email protected] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
Jeremy Chadwick wrote: [...] 2) I tend to keep a large amount of logs on systems, going back weeks if not months. This is intentional; it's amazing how often a customer or user will ask for some information from 3 or 4 months prior. FreeBSD's Apache port out-of-the-box logs to /var/log/httpd-*, and what we do is mostly web content serving. Let's also not forget about /var/log/maillog. I also advocate use of /var/log/all.log. I think it's fairly well-established at this point that I focus on server environments and not workstations (where /var probably doesn't need to be anywhere near that size). Folks should always review their needs, keeping expansion possibility in mind, when doing filesystem creation. I keep log files (apache, lighttpd, proftpd, maillog) about 2 weeks on the machine (rotated daily), but I have them all for minimal 3 months on our central backup machine (I have most logs archived for more than 1 year - depending on free space of the backup storage ;]) And why so big /tmp? I am running servers with smaller sizes for years without any problem. My recommendation above doesn't imply those who don't use it will have problems -- each environment/system is different. That said, it's amazing how much software out there blindly uses /tmp. Last year I ran into this situation: an older server (1GB /tmp) started behaving oddly due to /tmp filling. A user of the system was using lynx to download some large files (an ISO image and something else, I forget what). lynx saves data its downloading to /tmp, and once it completes, the user is prompted where to save the data (CWD being the default). "So tune lynx to use /var/tmp or some other path" -- sure, that'd work, except lynx is just one of many programs which could do this. I'd rather not "tune them all". :-) /tmp is more or less universal. Most of our servers are without shell users and without programs like lynx :) So I hope I am safe with 1-2GB /tmp (I don't remember any accident with "no space left on device /tmp" for past 4-5 years. Maybe I am just lucky guy ;) Hope this sheds some light on my decisions. :-) Thank you for you explanation, it makes sense in your environment. Miroslav Lachman ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Sat, Jan 23, 2010 at 09:04:57PM +0100, Miroslav Lachman wrote: > Jeremy Chadwick wrote: > > [...] > > >While I'm here, I figure I'd share how I end up partitioning most of the > >server systems I maintain. I use this general "formula" when building a > >new system, unless it's a 4-disk box (see bottom of mail): > > > >ad4s1a = /= UFS2= 1GB > >ad4s1b = swap = (2*RAM) or (2*MaxRAMPossible) > >ad4s1d = /var = UFS2+SU = 16GB (mandatory: must be>= 2*RAM) > >ad4s1e = /tmp = UFS2+SU = (2*RAM) > >ad4s1f = /usr = UFS2+SU = 16GB > > Why you are suggesting /var >= 2*RAM? Is it just for saving crash > dumps or anything else? 1) Kernel panics/crash dumps are a big focus, yes. There's nothing worse than experiencing one, only to find out that savecore(8) can't do its job because /var/crash lacks the space. The system then boots anyway, swap starts getting used as normal, and the dump is therefore lost. Chance of debugging this post-mortem: zero. Additionally, people these days are often upgrading RAM in their systems as well; they start out with 1-2GB and create /var possibly with the knowledge of the above ordeal (re: crash dumps). Then they later upgrade to 4GB or 8GB RAM, and suddenly realise that they can't grow /var to deal with a crash dump. 2) I tend to keep a large amount of logs on systems, going back weeks if not months. This is intentional; it's amazing how often a customer or user will ask for some information from 3 or 4 months prior. FreeBSD's Apache port out-of-the-box logs to /var/log/httpd-*, and what we do is mostly web content serving. Let's also not forget about /var/log/maillog. I also advocate use of /var/log/all.log. I think it's fairly well-established at this point that I focus on server environments and not workstations (where /var probably doesn't need to be anywhere near that size). Folks should always review their needs, keeping expansion possibility in mind, when doing filesystem creation. > And why so big /tmp? I am running servers with smaller sizes for years > without any problem. My recommendation above doesn't imply those who don't use it will have problems -- each environment/system is different. That said, it's amazing how much software out there blindly uses /tmp. Last year I ran into this situation: an older server (1GB /tmp) started behaving oddly due to /tmp filling. A user of the system was using lynx to download some large files (an ISO image and something else, I forget what). lynx saves data its downloading to /tmp, and once it completes, the user is prompted where to save the data (CWD being the default). "So tune lynx to use /var/tmp or some other path" -- sure, that'd work, except lynx is just one of many programs which could do this. I'd rather not "tune them all". :-) /tmp is more or less universal. Hope this sheds some light on my decisions. :-) -- | Jeremy Chadwick [email protected] | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
Jeremy Chadwick wrote: [...] While I'm here, I figure I'd share how I end up partitioning most of the server systems I maintain. I use this general "formula" when building a new system, unless it's a 4-disk box (see bottom of mail): ad4s1a = /= UFS2= 1GB ad4s1b = swap = (2*RAM) or (2*MaxRAMPossible) ad4s1d = /var = UFS2+SU = 16GB (mandatory: must be>= 2*RAM) ad4s1e = /tmp = UFS2+SU = (2*RAM) ad4s1f = /usr = UFS2+SU = 16GB Why you are suggesting /var >= 2*RAM? Is it just for saving crash dumps or anything else? And why so big /tmp? I am running servers with smaller sizes for years without any problem. (I am not using crash dumps and if I need it, it seems better to use dumpdir="/my/large/storage") Miroslav Lachman ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Sat, Jan 23, 2010 at 10:43:49PM +1030, Daniel O'Connor wrote: > On Sat, 23 Jan 2010, Ruben de Groot wrote: > > To be a little more precise: it's not the >kernel< that is so big. > > It's all the (mostly not needed) modules and symbol files that fill > > up / > > Maybe they could be put somewhere else.. I have a stupid question: Why are modules built and installed for things that are already included in the kernel? That would seem (I haven't looked) to be a simple change that would both speed up builds and shrink /boot/kernel. -- Barney Wolff I never met a computer I didn't like. ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Sat, 23 Jan 2010, Ruben de Groot wrote: > On Sat, Jan 23, 2010 at 01:23:28AM +, Adrian Wontroba typed: > > I concur that the 235 MB size of an amd64 8.0 kernel is a bit of a > > surprise. An i386 kernel is a mere 135 MB. IMO increasing the > > sysinstall default root slice size for at least amd64 would be a > > good thing. > > To be a little more precise: it's not the >kernel< that is so big. > It's all the (mostly not needed) modules and symbol files that fill > up / Maybe they could be put somewhere else.. I don't think you need them unless remote debugging and in that case you are multiuser (I would have thought anyway). If they went into /usr then /boot could remain slim. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: 8.0-RELEASE -> -STABLE and size of /
On Sat, Jan 23, 2010 at 01:23:28AM +, Adrian Wontroba typed: > I concur that the 235 MB size of an amd64 8.0 kernel is a bit of a > surprise. An i386 kernel is a mere 135 MB. IMO increasing the sysinstall > default root slice size for at least amd64 would be a good thing. To be a little more precise: it's not the >kernel< that is so big. It's all the (mostly not needed) modules and symbol files that fill up / ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Friday 22 January 2010 06:32:02 pm Oliver Brandmueller wrote: > Hi, > > On Fri, Jan 22, 2010 at 03:56:31PM -0500, Steven Friedrich wrote: > > in your /etc/make.conf, do you have a line like: > > makeoptions DEBUG=-g > > if so, comment it out. > > The GENEREIC kernel by default has the following config: > > makeoptions DEBUG=-g# Build kernel with gdb(1) debug > symbols > > You don't need anything special in your make.conf > > In fact having the debug symbols is useful in many cases. So raising the > default size for the / partition might be the better option (OK, doesn't > help for already installed systems of course). > > - Oliver > I'm sorry. My response to him should have been more precise. I was trying to clue him in on how to build a non-debug kernel, but my answer was in fact wrong. I said he may have a line in make.conf, but that was a mistake. I pulled the line from a kernel config file. If he wants to build a kernel with no symbols, as he stated he does, he needs to comment out the line and build a kernel. Could buildworld and installworld, too. But he and I went off topic. I should have changed the subject line to start a new thread to discuss building without symbols. He was complaining that it wasn't in the FAQ or the handbook. It's in GENERIC, which is required reading if you're ever going to build custom kernels. As for the main topic, I have been making 4GB root partitions for some time. Our disk requirements have been soaring over the last decade, while cost per MB have plummeted. I don't want to have to guess what sizes each partition should be. ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Fri, Jan 22, 2010 at 05:21:56PM +0100, Oliver Brandmueller wrote: > > I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default > 512M. First step after setup was to csup to RELENG_8 and buildkernel and > buildworld (no custom kernel, no make.conf). > > Instaling the new kernel failed, since /boot/kernel/ is already well > over 230 MBytes in size. moving that to kernel.old and writing a new one > with about the same size fails due to no space left on device. > > This is not a question; I do know how to get around this and how to > configure custom kernels so they are a fragment of that size afterwards. > However, I think this is a clear POLA violation. So, either GENERIC with > less debugging information (symbols and stuff), which makes debugging > harder or setting a higher default for / would be options, if not anyone > else has better ideas. /usr/src/UPDATING has this which will allow you to remove symbols when installing a kernel: 20060118: This actually occured some time ago, but installing the kernel now also installs a bunch of symbol files for the kernel modules. This increases the size of /boot/kernel to about 67Mbytes. You will need twice this if you will eventually back this up to kernel.old on your next install. If you have a shortage of room in your root partition, you should add -DINSTALL_NODEBUG to your make arguments or add INSTALL_NODEBUG="yes" to your /etc/make.conf. I concur that the 235 MB size of an amd64 8.0 kernel is a bit of a surprise. An i386 kernel is a mere 135 MB. IMO increasing the sysinstall default root slice size for at least amd64 would be a good thing. -- Adrian Wontroba ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
Hi, On Fri, Jan 22, 2010 at 03:56:31PM -0500, Steven Friedrich wrote: > in your /etc/make.conf, do you have a line like: > makeoptions DEBUG=-g > if so, comment it out. The GENEREIC kernel by default has the following config: makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols You don't need anything special in your make.conf In fact having the debug symbols is useful in many cases. So raising the default size for the / partition might be the better option (OK, doesn't help for already installed systems of course). - Oliver -- | Oliver Brandmueller http://sysadm.in/ [email protected] | |Ich bin das Internet. Sowahr ich Gott helfe. | ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Friday 22 January 2010 11:46:01 am Torfinn Ingolfsen wrote: > On Fri, 22 Jan 2010 17:21:56 +0100 > > Oliver Brandmueller wrote: > > Instaling the new kernel failed, since /boot/kernel/ is already well > > over 230 MBytes in size. moving that to kernel.old and writing a new one > > with about the same size fails due to no space left on device. > > > > This is not a question; I do know how to get around this and how to > > configure custom kernels so they are a fragment of that size afterwards. > > It would also be nice if we knew how to configure the > whole "make world" procedure[1] to make a new kernel and modules without > symbols. The FAQ doesn't seem to have that answer either. > > > References: > 1) http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > in your /etc/make.conf, do you have a line like: makeoptions DEBUG=-g if so, comment it out. ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Fri, Jan 22, 2010 at 05:27:52PM +0100, Marian Hettwer wrote: > Hi All, > > On Fri, 22 Jan 2010 17:21:56 +0100, Oliver Brandmueller > wrote: > > Hi, > > > > I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default > > 512M. First step after setup was to csup to RELENG_8 and buildkernel and > > buildworld (no custom kernel, no make.conf). > > > > Instaling the new kernel failed, since /boot/kernel/ is already well > > over 230 MBytes in size. moving that to kernel.old and writing a new one > > with about the same size fails due to no space left on device. > > > > This is not a question; I do know how to get around this and how to > > configure custom kernels so they are a fragment of that size afterwards. > > However, I think this is a clear POLA violation. So, either GENERIC with > > less debugging information (symbols and stuff), which makes debugging > > harder or setting a higher default for / would be options, if not anyone > > else has better ideas. > > > +1 vote for making / bigger. > At least a size where a make installkernel runs through. > > I like FreeBSD because it honors POLA. > And as Oliver stated, this is a clear POLA violation. I'd like to see the default root filesystem size default to 1GB. For most folks this works well. If people are paranoid, 2GB should be more than sufficient. While I'm here, I figure I'd share how I end up partitioning most of the server systems I maintain. I use this general "formula" when building a new system, unless it's a 4-disk box (see bottom of mail): ad4s1a = /= UFS2= 1GB ad4s1b = swap = (2*RAM) or (2*MaxRAMPossible) ad4s1d = /var = UFS2+SU = 16GB (mandatory: must be >= 2*RAM) ad4s1e = /tmp = UFS2+SU = (2*RAM) ad4s1f = /usr = UFS2+SU = 16GB There's lots of leftover space on the disk of course -- for either ad4s1g or ad4s2. For 1-disk boxes, I add ad8s1g = /home = UFS2+SU = , or sometimes name it /storage (depends on the role of the box). For 2-disk boxes, I almost always go with disks that are identical in size, use the above formula, and add ZFS mirroring as so: ad4s2 = ZFS mirror pool = ad6= ZFS mirror pool = Then /home or /storage are ZFS filesystems in that pool. Folks will say "but that means you're losing/wasting gigs of space on ad6, since the mirror size is based on the smallest pool member!" Yep, but I consider the trade off easily worth it. Given the size of disks today (500GB to 2TB), I really don't stress about it: Wasted space for 4GB RAM systems: 1 + 2*4 + 16 + 2*4 + 16 = 49GB Wasted space for 8GB RAM systems: 1 + 2*8 + 16 + 2*8 + 16 = 65GB If the machine is 4-disk, I use a slightly modified formula: ad4s1a = / = UFS2= 1GB ad4s1b = swap = (2*RAM) or (2*MaxRAMPossible) ad4s1d = /var = UFS2+SU = 16GB (mandatory: must be >= 2*RAM) ad4s1e = /tmp = UFS2+SU = (2*RAM) ad4s1f = /usr = UFS2+SU = 16GB ad4s1g = /spare = UFS2+SU = ad6= ZFS raidz1 pool = ad8= ZFS raidz1 pool = ad10 = ZFS raidz1 pool = The ad4s1g part might seem silly, but I've found it useful. If a filesystem like /var goes awry (usually if bad blocks exist on the disk where that filesystem lies), you can temporarily work around it by rsync'ing as much data over to /spare, then remount /spare as /var to avoid use of the sectors involved in ad4s1d. I've had to do this on two separate occasions. There are network backups for all the boxes, so I don't OCD about it all too much. :-) -- | Jeremy Chadwick [email protected] | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
On Fri, 22 Jan 2010 17:21:56 +0100 Oliver Brandmueller wrote: > Instaling the new kernel failed, since /boot/kernel/ is already well > over 230 MBytes in size. moving that to kernel.old and writing a new one > with about the same size fails due to no space left on device. > > This is not a question; I do know how to get around this and how to > configure custom kernels so they are a fragment of that size afterwards. It would also be nice if we knew how to configure the whole "make world" procedure[1] to make a new kernel and modules without symbols. The FAQ doesn't seem to have that answer either. References: 1) http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html -- Regards, Torfinn Ingolfsen ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
Re: 8.0-RELEASE -> -STABLE and size of /
Hi All, On Fri, 22 Jan 2010 17:21:56 +0100, Oliver Brandmueller wrote: > Hi, > > I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default > 512M. First step after setup was to csup to RELENG_8 and buildkernel and > buildworld (no custom kernel, no make.conf). > > Instaling the new kernel failed, since /boot/kernel/ is already well > over 230 MBytes in size. moving that to kernel.old and writing a new one > with about the same size fails due to no space left on device. > > This is not a question; I do know how to get around this and how to > configure custom kernels so they are a fragment of that size afterwards. > However, I think this is a clear POLA violation. So, either GENERIC with > less debugging information (symbols and stuff), which makes debugging > harder or setting a higher default for / would be options, if not anyone > else has better ideas. > +1 vote for making / bigger. At least a size where a make installkernel runs through. I like FreeBSD because it honors POLA. And as Oliver stated, this is a clear POLA violation. Cheers, Marian ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
8.0-RELEASE -> -STABLE and size of /
Hi, I just noticed somthing: I setup an 8.0-RELEASE amd64 box, / is default 512M. First step after setup was to csup to RELENG_8 and buildkernel and buildworld (no custom kernel, no make.conf). Instaling the new kernel failed, since /boot/kernel/ is already well over 230 MBytes in size. moving that to kernel.old and writing a new one with about the same size fails due to no space left on device. This is not a question; I do know how to get around this and how to configure custom kernels so they are a fragment of that size afterwards. However, I think this is a clear POLA violation. So, either GENERIC with less debugging information (symbols and stuff), which makes debugging harder or setting a higher default for / would be options, if not anyone else has better ideas. - Oliver -- | Oliver Brandmueller http://sysadm.in/ [email protected] | |Ich bin das Internet. Sowahr ich Gott helfe. | ___ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
