Re: userspace pagecache management tool

[Ray Lee]

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...
	ray@phoenix:~$ 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/