[Gluster-users] booster
Mark Mielke
mark at mark.mielke.cc
Mon Sep 14 14:17:59 UTC 2009
On 09/14/2009 06:31 AM, Stephan von Krawczynski wrote:
>> 2. running bash wasnt a very useful scenario when the LD_PRELOAD
>> variable can be added for the bash environment as a whole. For eg.
>> if you just do "export LD_PRELOAD=<blah>" on the command line, you can
>> actually have every program started from that shell use booster.
>>
>> -Shehjar
>>
> There is a problem with that: if your bash environment calls only one other
> bash-script it will fail either. Another problem can be script-replaced
> binaries. If you replace some classical binary with a shell-script for
> additional parameters (or any other thinkable reason) this general export
> approach will fail, too.
> Or lets say your favourite email client calls some script to mark spam...
> There are a lot of black holes in this ground ...
>
I'm pretty sure it's related to a previous thread I started - booster
does not require glibc to be compiled with --no-hidden-plt. This means
that any functions glibc runs that execute *other* system calls, such as
fopen() calling open(), do not get intercepted, on modern Linux
distributions. This would be a huge problem for most applications as
STDIO is more common than not. (There are probably other system calls
not intercepted as well)
Booster may work fine for applications that are designed for
performance, that avoid the STDIO layer, and stick to common "system
calls" such as open(), read(), write(), fsync(), close(). Bash is
probably not one of these.
For hidden PLT, because I think people didn't understand what I was
talking about in the previous thread and I let it go - GLIBC
purposefully uses a "hidden PLT", such that any time GLIBC calls open()
from within itself, it will normally use it's OWN version, even if
open() is overridden using a scheme such as LD_PRELOAD. The two main
arguments for this are: 1) Reduce chance of LD_PRELOAD screwing GLIBC
up, and 2) Slightly better performance. Solutions such as LUFS and
several others including our home grown solution, require GLIBC to be
built with --no-hidden-plt to disable this feature, and allow override
of open() to affect GLIBC's use of open(), such as fopen() calling open().
Cheers,
mark
--
Mark Mielke<mark at mielke.cc>
More information about the Gluster-users
mailing list