Re: invalidate the buffer heads of a block device

[Jan Kara <jack@suse.cz>]

On Tue 30-09-14 17:13:19, Trond Myklebust wrote:
> On Tue, Sep 30, 2014 at 4:53 PM, Zach Brown <zab@zabbo.net> 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.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR