On Wed, Oct 1, 2014 at 5:05 AM, Jan Kara <jack@xxxxxxx> wrote:
> On Tue 30-09-14 17:13:19, Trond Myklebust wrote:
>> On Tue, Sep 30, 2014 at 4:53 PM, Zach Brown <zab@xxxxxxxxx> wrote:
>> > On Tue, Sep 30, 2014 at 12:48:45PM +0200, Jan Kara wrote:
>> >> On Tue 30-09-14 10:11:32, Thanos Makatos wrote:
>> >> >
>> >> > Regarding extending the ioctl to invalidate the page cache, do you have
>> >> > any suggestions where I could start looking?
>> >> You just need to call invalidate_inode_pages2(). That is going to do all
>> >> you need.
>> >>
>> >> > Would such a new ioctl have any chance to be accepted upstream?
>> >> I believe a possibility for a file to be fully flushed from page cache is
>> >> useful at times and if you present well your usecase there are reasonable
>> >> chances it will get accepted upstream.
>> >
>> > Agreed, this seems reasonable. How many times have we all dropped our
>> > entire cache just 'cause we didn't have a more precise tool?
>> >
>> > $ grep -ri drop_caches xfstests/
>> > xfstests/src/fsync-tester.c: if ((fd = open("/proc/sys/vm/drop_caches", O_WRONLY)) < 0) {
>> > xfstests/src/stale_handle.c: system("echo 3 > /proc/sys/vm/drop_caches");
>> > xfstests/common/quota: echo 3 > /proc/sys/vm/drop_caches
>> >
>> > The last one even says:
>> >
>> > # XXX: really need an ioctl instead of this big hammer
>> > echo 3 > /proc/sys/vm/drop_caches
>> >
>> > :)
>> >
>>
>> It would definitely be useful for NFS, however we'd want the option of
>> clearing the cached metadata too (acls, mode bits, owner/group owner,
>> etc.)
> Hum, I can imagine you might be somehow successful in flushing ACLs but
> how would you like to flush mode or owner? It's not like you can just
> reload inode from disk and overwrite what you have in memory. What would
> look sane is to push inode with all metadata it caches out of memory but
> once somehow holds the inode (and ioctl() itself will have a file handle of
> the inode), you just cannot. So I'm not sure if you meant something
> different or if this was just a wish without deeper thought.
You can and you _must_ reload the inode if it changes on the server.
That's what makes distributed filesystems "interesting" as far as
caching goes. What we do in the cases where we think the file metadata
may have changed, is to mark the existing cached metadata as being
stale so that we know that we need to revalidate before trying to use
it.
So being able to tell in the ioctl() whether or not the application
thinks the data or metadata (or both) may have changed on the remote
disk is actually a very useful feature if you are trying to do things
like distributed compiles.
I've had an experimental NFS-only ioctl() based caching interface
kicking around in my git repository for a couple of years now
(http://git.linux-nfs.org/?p=trondmy/linux-nfs.git;a=shortlog;h=refs/heads/ioctl).
If we are planning on doing something at the VFS level, then it would
be nice to at least duplicate the functionality from the first 2
patches.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
