On 09/07/2011 05:10 AM, Gordan Bobic wrote:
I just thought of another reason to not use prelink - incremental
backups. Prelinking will change the binaries every time it is run thus
triggering an unnecessarily large backup. Couple that with the fact that
it will nullify the advantage gained from de-duplicating storage. For
example, my backup solution is lsyncd triggering rsync going to a copyfs
backed by zfs with deduplication. Multiply that increase in
bandwidth/storage requirements with a potentially large number of
machines and the problem becomes non-trivial.
So, to summarize, the list of reasons not to use it thus far:
- incremental backups
- tripwire-like IDS
- increased unnecessary flash wear
- renders vserver hashify ineffective
I accept that there may be cases where it is useful in some measure - I
just don't think it should be on by default.
Gordan
Hi Gordan,
In the case of having multiple guest virtual machines on the same physical machine having
something like prelink modify the binaries would make it harder to find those identical
files. However, in many cases for ARM people are running code on small physical arm
machines. Using prelink to make more of the memory read-only could help performance on
these small memory machines. It would be nice to have the option of using prelink on ARM
in these situations.
How much additional wear to the flash device would running a daily cron job going to add?
It isn't modififying a sector hundreds of times a minute continuously.
Is there a lot of rpm changes going on in your environment? /etc/cron.daily/prelink
appears to take some measure to minimize the amount of work it does by using quick mode
(-q) most of the time.
-Will