[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Make hardlinking kernel-devel optional

On Tue, Jan 31, 2006 at 07:26:03PM -0600, Chris Adams wrote:

 > If you don't have a huge number of kernels installed, hardlink isn't a
 > big benefit.  The kernel-devel package is 14MB installed.  Hardlinking
 > with 3 kernel-devel packages installed will save no more than 28MB (and
 > probably less).  That is lost in the noise of a normal system.  Just
 > doing "yum update" will often use much more than 28MB; even after a "yum
 > clean packages" on a rawhide system I see 90MB in /var/cache/yum.

"We can spew 28MB in app X because app Y spews 90MB" doesn't make
a great deal of sense.  The cumulative effects if every package
took the same attitude would be a vastly bloated minimal install.

 > Also, hardlink apparently may not be very efficient.  I whipped up a
 > version in perl that (in my limited testing) appears faster.  Others
 > have written C and C++ (and maybe IIRC python) versions that also appear
 > to be faster.  How about replacing it with something better performing?

File a bug against it with patches, and I'm sure jnovy redhat will be interested.

 > The solution of "rpm -e hardlink" is also not very good, as some people
 > use hardlink for other things (and so can't just remove it).


 > As a compromise, how about only kicking hardlink off if there are more
 > than X kernel-devel packages installed (where X is more than the norm,
 > like 5)?  Or how about making the hardlink run as a cron job?

I'll merge Ignacio's change to source /etc/sysconfig/kernel, in addition
to the other change, 

 > Another though: why the "find | while ; do hardlink"?  You should just
 > be able to do:
 > if [ -x /usr/sbin/hardlink ] ; then
 >   /usr/sbin/hardlink /usr/src/kernels/*FC*
 > fi
 > The post script is forking hardlink over 5000 times as well as causing
 > thousands of repeated directory lookups by find and the shell (that
 > hardlink then has to do anyway), instead of just letting one run of
 > hardlink do its job (it should recurse just fine).

I've often wondered why it was written that way too.
Arjan, do you recall ?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]