Date: Thu, 30 Oct 2014 13:21:27 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: freebsd-current@freebsd.org Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ Message-ID: <54523B57.1010802@multiplay.co.uk> In-Reply-To: <EEFB6867-A317-4BEF-B219-D26ACDF9622E@lists.zabbadoz.net> References: <CAPyFy2APVUxpAztmWY-ux7gUZ7B8Qk65CLHV_fVYmxsazKgCPg@mail.gmail.com> <54511A7E.1020307@multiplay.co.uk> <CAPyFy2Bw9JH4w0iZ5hj2R1Ga9T4BZn_Z-8UBJ-jT6tmO%2Bi8VeA@mail.gmail.com> <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> <EEFB6867-A317-4BEF-B219-D26ACDF9622E@lists.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30/10/2014 12:10, Bjoern A. Zeeb wrote:
> On 30 Oct 2014, at 09:47 , O'Connor, Daniel <Daniel.O'Connor@emc.com> wrote:
>
>> On 30 Oct 2014, at 19:44, Steven Hartland <killing@multiplay.co.uk> wrote:
>>> On 30/10/2014 08:24, O'Connor, Daniel wrote:
>>>> On 30 Oct 2014, at 13:23, Steven Hartland <killing@multiplay.co.uk> 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’s not “a little bit” of space.
>>>> [freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i += $5} END {print $5}'
>>>> 49312
>>>> [freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i += $5} END {print $5}’
>>>> 212464
>>>>
>>>> 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.
>> Yes.
> No it is not a trivial amount of space; it’s about 20ish% of the installation of the base system.
It may be a decent percentage but when that's a percentage of a small
number its still results in a trivial amount of space in the grand
scheme of things, which was my point ;-)
> 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 thing to keep in mind, if we don't have symbols installed is how we
create useful panic information.
> 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.
Yes and no, generating useful information from a users panic issue is
something we really need to ensure is still possible. As where they
aren't the developer, they are the source of the information.
So maybe some sort of post processing utility?
> (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.
Assuming the above is solved yes.
> (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.
Are you suggesting you only backup your root partition and not your usr
partition, as if so its a null argument as the total size is still the same.
I'm assuming not and your saying we shouldn't install debug at all,
which has the above side effect.
> (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’d 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’t.
Sounds like having a way to not install symbols to the root partition
for *binary* installs is the real requirement?
So having an alternative location off root would be solution.
> (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’s in Antarctica on a 9600 baud connection?
While I appreciate such systems exist surely given your previous point
where you actually don't want them installed at all, so providing that
option instead of moving them to a different location can causing a load
more issues is a better solution is it not?
> (f) …
>
> 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’d expect a user to ever do. But I am aware that’s a “developer standard”. Maybe we just need to improve the situation for ourselves rather than pessimising 98% of users out there.
Indeed.
> 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’t 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?
>
That sounds totally reasonable. We just need to have someway to easily
post generate the useful information we currently get from a panic when
the user doesn't have symbols installed.
I think overall there's options to move forward, we just need to ensure
its not at the expense of usability for those that do have space.
Regards
Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54523B57.1010802>