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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
