From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 12:10:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F72C743; Thu, 30 Oct 2014 12:10:21 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FD0CD4; Thu, 30 Oct 2014 12:10:19 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A363A25D37C7; Thu, 30 Oct 2014 12:10:09 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 671F6C7709B; Thu, 30 Oct 2014 12:10:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 5rUgvv2gS7jd; Thu, 30 Oct 2014 12:10:05 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id DF247C77057; Thu, 30 Oct 2014 12:10:04 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ From: "Bjoern A. Zeeb" In-Reply-To: <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> Date: Thu, 30 Oct 2014 12:10:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54511A7E.1020307@multiplay.co.uk> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> <54520177.5000008@multiplay.co.uk> <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> To: FreeBSD Current X-Mailer: Apple Mail (2.1878.6) Cc: Ed Maste X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:10:21 -0000 On 30 Oct 2014, at 09:47 , O'Connor, Daniel = wrote: > On 30 Oct 2014, at 19:44, Steven Hartland = wrote: >> On 30/10/2014 08:24, O'Connor, Daniel wrote: >>> On 30 Oct 2014, at 13:23, Steven Hartland = wrote: >>>> Making things harder to manage vs saving a little bit of space on = the >>>> root partition really doesn't sound like a good idea; especially = when >>>> with the ZFS install, which I would suggest is becoming the norm, = the >>>> root partition doesn't suffer from space issues anyway. >>> Note that it=92s not =93a little bit=94 of space. >>> [freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i +=3D $5} END = {print $5}' >>> 49312 >>> [freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i +=3D $5} END = {print $5}=92 >>> 212464 >>>=20 >>> i.e. the debug information is more than 4x larger than the code its = for (!). >> That's still a trivial about of space in the grand scheme of things. >=20 > Yes. No it is not a trivial amount of space; it=92s about 20ish% of the = installation of the base system. I guess I am one source for the request to get them out of = /boot/kernel/*.symbols into a spearate tarball and not install them by = default for users. The reasons for me are indeed manyfold: (a) symbol files are for developers. Developers are clever people, = often with custom systems, they know how to deal with them as they = already do whatever they want anyway in 7 different ways. (b) A user should usually never have to bother with them, so why have = them installed in first place? They go onto (release) the media so that = developers have access to them, or that users, if guided by a developer, = can install them to debug a problem. Moving them to a separate = directory and into a different tarball makes that a lot easier. (c) We have people deploying gazillions of FreeBSD systems from default = media, this stuff does add up; 10TB sounds small unless you have to = back it up regularly, need disaster copies, or you need to minimise = recovery or migration time, when every s is worth a few $$s. (d) A couple of times a year I do spare VM image backup and recovery = including migration. Moving the data back and forth can only happen in = a very limited time frame, so I try to keep these VM images as small as = possible. rm -f /boot/kernel/*.symbol after install is really not = keeping the sparseness as no one really supports TRIM on the VM images. = Thus I=92d just have lost 200MB * n VMs that I need to move around over = 200ms RTT. There are cruel workarounds; I know how to apply them as I = am a developer, but if I do this stuff, there must be 1000s of users = doing that, and they don=92t. (e) People still have / (boot) filesystems in the 256M-1G space for the = foreseeable future. How do you ever cramp two kernels in there during = an update for a machine that you will never ever see again because it=92s = in Antarctica on a 9600 baud connection? (f) =85 Yes I can understand that on these 40TB ZFS machines, no one gives a = damn about 200MB, but unfortunately not the entire world runs on these = kinds of machines. We have plenty of users on 10 year old hardware = still running a FreeBSD installation and it works perfectly fine and = does the job (until the HW dies;-). The entire cp -pR kernel kernel.good solution is nothing I=92d expect a = user to ever do. But I am aware that=92s a =93developer standard=94. = Maybe we just need to improve the situation for ourselves rather than = pessimising 98% of users out there. I personally do not mind where the symbol files will end up as long as = they are in their own directory and not onto systems by default with = releases unless someone ticks a box. Whether that is = /boot/kernel/symbols/* or /usr/lib/***, I couldn=92t care less, apart = from the fact that /boot remains on a space constrained file system for = a lot of legacy system that symbol files have filled up more than once = for me in the past. So maybe the real solution is indeed for developers to think how to = manage kernels and related files and settings in the future? =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983