That sounds like a good idea but you would need to blacklist the PIDs of
the commands called from your backup script as well.  Most likely, they are
the processes opening all of the files to start with.  You might want to
look at using a python script for your backup script so you can more easily
capture the PIDs of the executed commands.


On Thu, Jun 6, 2013 at 10:47 AM, Giacomo Mulas
<gmu...@oa-cagliari.inaf.it>wrote:

> Hello everybody.
>
> I am looking for hints to create a wrapper for an arbitrary command, so
> that
> I can set a ioctl using its PID and reset the ioctl after the command is
> finished.
>
> The problem I need to solve is the following: I have an hybrid spinning+ssd
> drive on my laptop, and I set up flashcache to use the small (~20G) ssd to
> cache the 500G spinning disk. It works well, but is defeated every time a
> backup runs, or any cron job which goes through the whole disk, thereby
> very
> effectively wiping the cache (i.e. throwing away the most frequently used
> data from the cache and making it useless until it is repopulated).
> Flashcache does offer the possibility to "blacklist" PIDs so that they will
> not go through the cache. It cannot remove the PIDs automatically, so they
> must be removed from the blacklist after the process finishes.
> So my idea would be to use wrappers which call flashcache_setioctl before
> the command to be blacklisted, and immediately after it is finished.
> Setting is easy: I can just do, e.g.
>
> flashcache_setioctl -a -b $$ /dev/mapper/mycache ; this adds the current
> PID
>                                                  ; to the black list
> exec mycommand $@
>
> however, in this way the shell exits after mycommand finishes, and I cannot
> add at the end the final command
>
> flashcache_setioctl -r -b $$ /dev/mapper/mycache
>
> which would remove the PID from the black list of the cache.
>
> Can someone suggest a way to wrap a command so that I can know its PID
> (before it is launched or immediately after) and get back control when it
> is
> finished? It sounds relatively easy, and more general than my specific
> problem, I would be surprised if noone else has yet faced a similar case
> (and solved it).
>
> Thanks, bye
> Giacomo
>
> --
> ______________________________**______________________________**_____
>
> Giacomo Mulas <gmu...@oa-cagliari.inaf.it>
> ______________________________**______________________________**_____
>
> OSSERVATORIO ASTRONOMICO DI CAGLIARI
> Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)
>
> Tel. (OAC): +39 070 71180 248     Fax : +39 070 71180 222
> Tel. (UNICA): +39 070 675 4916
> ______________________________**______________________________**_____
>
> "When the storms are raging around you, stay right where you are"
>                          (Freddy Mercury)
> ______________________________**______________________________**_____
>
>
> --
> To UNSUBSCRIBE, email to 
> debian-amd64-REQUEST@lists.**debian.org<debian-amd64-requ...@lists.debian.org>
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/**alpine.DEB.2.10.1306061630310.**
> 6...@capitanata.oa-cagliari.**inaf.it<http://lists.debian.org/alpine.deb.2.10.1306061630310....@capitanata.oa-cagliari.inaf.it>
>
>

Reply via email to