Andrew Morton wrote: > <wonders about sys_reclaim_dentry(const char *pathname)>
Would there be any other users of it than updatedb? I'm not coming up with much, but given that I'm not always clever, that doesn't mean much. <thinks out loud...> A hypothetical on-demand file virus scanner is going to hit already cached or about-to-be-cached entries by definition. Perhaps some system audit daemon, such as tripwire. Well, that has the same access patterns as updatedb, doesn't it: a directory at a time. find, cp -a, the same. So instead of sys_reclaim_dentry, how about extending fadvise to work on the fd returned via opendir? And extending POSIX_FADV_NOREUSE on a file fd to drop the dentry at close? (Call me chicken; I just don't want to be the guy suggesting a new syscall for a single or few users.) ~ ~ Alternately, there have been requests for a way for userspace to get notification of all file events for indexing of data and metadata (inotify, unfortunately, doesn't scale to a full filesystem). (cf. http://lkml.org/lkml/2006/9/30/98 .) That'd allow an updatedb daemon to keep the index up to date all the time, amortizing the cost. More usefully, it'd allow a content indexing daemon to stay up to date all the time, though inotify mostly works for those, I suppose. (Hmm... [EMAIL PROTECTED]:~$ find ~ -type d | wc -l 14067 ...right. So it probably works fine for normal people.) Hey, waitaminute. This should be a solved problem? SELinux must have some sort of requirement for logging file access attempts. Google, at least, implies so. Perhaps whatever it implements could be lifted into the core kernel without dragging the rest behind it. Dunno. Who do we CC? Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
