Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
From: Fredrik Klasson <hidden>
Date: 2007-07-26 13:05:16
On 7/26/07, Ingo Molnar [off-list ref] wrote:
quoted hunk ↗ jump to hunk
--- /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