On 7/26/07, Ingo Molnar <mingo@elte.hu> wrote:
--- /etc/cron.daily/mlocate.cron.orig
+++ /etc/cron.daily/mlocate.cron
@@ -1,4 +1,7 @@
#!/bin/sh
nodevs=$(< /proc/filesystems awk '$1 == "nodev" { print $2 }')
renice +19 -p $$ >/dev/null 2>&1
+PREV=`cat /proc/sys/vm/vfs_cache_pressure 2>/dev/null`
+echo 0 > /proc/sys/vm/vfs_cache_pressure 2>/dev/null
/usr/bin/updatedb -f "$nodevs"
+[ "$PREV" != "" ] && echo $PREV > /proc/sys/vm/vfs_cache_pressure 2>/dev/null
_______________________________________________
http://ck.kolivas.org/faqs/replying-to-mailing-list.txt
ck mailing list - mailto: ck@vds.kolivas.org
http://vds.kolivas.org/mailman/listinfo/ck
 
uhm... pardon my ignorance, but, doesn't this hack create a possible race condition?
Ie, this job starts, and while updatedb runs some other app/script (let's call it Gort) pokes with vfs_cache_pressure (saving 10000, as it's the current value), then updatedb finishes, and then a while after that Gort stops, "restoring" vfs_cache_pressure to 10000 instead of $PREV?

What we _really_ want is an updatedb that
does not disturb the dcache.
just a thought, the problem seems (to me, a mere mortal at best) to be that the functions/program doing the magic messes up caches. Wouldn't the easiest/obvious solution/hack be to use/write an "uncached_" version of those functions/apps? (or one that just reads the cache, but never upsets it by writing to it). Or is that impossible/impractical for some reason? (or worse yet, have I completely missed the point?)

--
... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself.
- Bradley Kuhn