Re: statfs() / statvfs() syscall ballsup...

[Andrea Arcangeli <andrea@suse.de>]

On Fri, Oct 10, 2003 at 11:05:35AM -0700, Joel Becker wrote:
> thinking, knowing now that there's possibility to move to a more optimal
> interface.

cleaner and simpler could very well be (many simpler db works that way
infact), but more optimal I doubt. To be more optimal you should let the
kernel do all the garbage collection of mappings, and not use
remap_file_pages. But then I'm unsure if the kernel is really able
better than you to choose what info to discard from the cache, and you'd
still have to pay for page faults that you don't have to right now.

And if you use remap_file_pages to still choose what to ""discard
first"" from userspace, then you'd better use O_DIRECT instead, that
doesn't require any pte mangling (ignoring the readahead, async-io and
msync, scsi-shared issues that sounds fixable).

About the security issues, they existed in older kernels they're
nowadays fixed thanks to Stephen's i_alloc_sem.

though, I'd be interesting to compared different models in practice to
be sure, I just don't have expectations for it being a "more optimal"
design at the moment.

Andrea - If you prefer relying on open source software, check these links:
	    rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
	    http://www.cobite.com/cvsps/