Date: Thu, 30 Oct 2014 12:10:03 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: FreeBSD Current <freebsd-current@freebsd.org> Cc: Ed Maste <emaste@freebsd.org> Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ Message-ID: <EEFB6867-A317-4BEF-B219-D26ACDF9622E@lists.zabbadoz.net> In-Reply-To: <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EEFB6867-A317-4BEF-B219-D26ACDF9622E>