Bug 132056 - In quick-mode, prelink does not ignore un-prelinkable executables (causing a significant slowdown)
In quick-mode, prelink does not ignore un-prelinkable executables (causing a ...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: prelink (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-08 08:31 EDT by ezolt
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 0.3.2-10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-02 13:03:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description ezolt 2004-09-08 08:31:42 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
When running in quick mode, prelink does not cache the fact that some
binaries can not be prelinked.   As a result it rescans them everytime
, even if prelink is running in quick mode.  This causes the disk to
grind and dramatically slows down the whole system. 

There are 3 types of executables that it retries during quick mode: 
1) Static Binaries
2) Shell Scripts
3) Binaries that rely on un-prelinkable binaries. (Such as OpenGL)

For 1&2, it would be nice if prelink cached that fact that these
executables can not be prelinked, and then in quick mode check their
ctime & mtime, and don't even try to read them if it already knows
that they can't be prelinked. 

For 3, it would be nice if prelink recorded which libraries are
causing the prelink to fail (Take the OpenGL case for example), and
record that with the binary in the cache. If that library or the
binary's ctime & mtime haven't changed, then don't even try to prelink
it.  If things have really changed, it will be picked up on the next
run of "prelink -af".



Version-Release number of selected component (if applicable):
prelink-0.3.2-1

How reproducible:
Always

Steps to Reproduce:
1.Run prelink -a -f on a directory with shell scripts & other
executables that can not be prelinked.
2. Strace "prelink -a -q", and look for the "reads".
3. Examine strace's output, and you'll see all of the reads that take
place.

Actual Results:  Shell script: 

  open("/bin/unicode_stop", O_RDONLY|O_LARGEFILE) = 5
  read(5, "#!/bin/sh\n# stop u", 18)      = 18
  close(5)                                = 0
....

Static Binary:
open("/bin/ash.static", O_RDONLY|O_LARGEFILE) = 5
read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0", 18) = 18
fcntl64(5, F_GETFL)                     = 0x8000 (flags
O_RDONLY|O_LARGEFILE)
pread(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0", 16, 0) = 16
pread(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0", 16, 0) = 16
pread(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\0\201\4"...,
52, 0) = 52
pread(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\0\201\4"...,
52, 0) = 52
pread(5, "\1\0\0\0\0\0\0\0\0\200\4\10\0\200\4\10\320d\7\0\320d\7"...,
128, 52) = 128
pread(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
920, 488632) = 920
close(5)    

Un-prelinkable executable:
lstat64("/usr/lib/mozilla-1.6/regchrome", {st_mode=S_IFREG|0755,
st_size=14444,
...}) = 0
open("/usr/lib/mozilla-1.6/regchrome", O_RDONLY|O_LARGEFILE) = 6
read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0", 18) = 18
fcntl64(6, F_GETFL)                     = 0x8000 (flags
O_RDONLY|O_LARGEFILE)
pread(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0", 16, 0) = 16
...
open("/usr/lib/mozilla-1.6/libldap50.so", O_RDONLY|O_LARGEFILE) = 6
read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0", 18) = 18
close(6)                                = 0
lstat64("/usr/lib/mozilla-1.6/libgtkxtbin.so", {st_mode=S_IFREG|0755,
st_size=14268, ...}) = 0
open("/usr/lib/mozilla-1.6/libgtkxtbin.so", O_RDONLY|O_LARGEFILE) = 6
read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0", 18) = 18
close(6)                                = 0
lstat64("/usr/lib/mozilla-1.6/libjsj.so", {st_mode=S_IFREG|0755,
st_size=96752,
...}) = 0
open("/usr/lib/mozilla-1.6/libjsj.so", O_RDONLY|O_LARGEFILE) = 6
read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0", 18) = 18
close(6)                                = 0
lstat64("/usr/lib/mozilla-1.6/mozilla-xremote-client",
{st_mode=S_IFREG|0755, st_size=12896, ...}) = 0
lstat64("/usr/lib/mozilla-1.6/regxpcom", {st_mode=S_IFREG|0755,
st_size=55144, ...}) = 0
lstat64("/usr/lib/mozilla-1.6/libgkgfx.so", {st_mode=S_IFREG|0755,
st_size=143012, ...}) = 0
open("/usr/lib/mozilla-1.6/libgkgfx.so", O_RDONLY|O_LARGEFILE) = 6
read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0", 18) = 18
close(6)                                = 0
...

Expected Results:  All of these should have been simple lstat checks
rather than actual reads of the executables. 

Additional info:

Note You need to log in before you can comment on or make changes to this bug.