First I went looking for an easy win and I believe there may be one to
be had in the fact that we include debuginfo for the ceph_test_*
binaries. Do we need to produce debuginfo for them? They currently
represent about 800+M on disk so could represent a quick and easy way
to reduce the size of the debuginfo we ship.
we do, so we can perform post-mortem debugging with the coredump if any
of them crashes in the qa run. but maybe their debuginfo is not necessary
for the builds intended be used by our users. but we still need to patch
rpm[1]. and looks like the upstream does not like this idea[2]. as discussed
over IRC, maybe we need to understand the "underlying problem", i.e.
who/what is the biggest contributor of the 800+M debuginfo before going
any further.
We looked into this some time ago with the conclusion that the ceph-test
package contains a rather large number of binaries (like 50), each of
which have a lot of the same library code statically linked. This, IIRC,
is the single biggest cause of the debuginfo bloat.
Kefu recently converted libcommon (statically linked) into the
libceph-common shared object (dynamically linked). That brought a major
reduction in the ceph-test debuginfo size (and build time/resource
utilization) but I guess there's still room for improvement in this area.
Regards,
Nathan
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
