Re: [Lsf-pc] [LSF/MM TOPIC] Network filesystem cache management system call

[Jeff Layton <jlayton@redhat.com>]

On Fri, 2017-01-06 at 16:18 -0700, Andreas Dilger wrote:
> On Jan 6, 2017, at 3:40 PM, David Howells <dhowells@redhat.com> wrote:
> > 
> > 
> > AFS filesystem implementations like OpenAFS have a number of management calls
> > usually implemented through the pioctl() and afs() system calls.  However,
> > there is general revulsion to the idea of allowing these in Linux as they are
> > very much abused.
> > 
> > Now, I need to come up with replacements for these.  For some I can use
> > getxattr()/setxattr(), for some keyrings and for others procfs/sysfs, but for
> > some I can't.
> > 
> > One of these is the call to manage local caching on a file or volume.  This,
> > however, doesn't really need to be limited to AFS, but could also be
> > applicable to NFS, CIFS, etc. - and possibly even to local filesystems.
> > 
> > A brainstorming session on this would be useful.
> 
> This is definitely something I'd like to discuss as well.  The posix_fadvise()
> call doesn't interact with the filesystem at all, so it isn't a useful source
> of cache management hints. 

That could be remedied though. Maybe a new file_operations member that
posix_fadvise could call when it's defined by the fs? I think it might
be useful to explore that avenue before proposing new interfaces.

> We've implemented a Lustre-specific ladvise hint
> using an ioctl to advise client and server caches, but having a generic hint
> API would be better.
> 

Agreed.

Ceph also has a private ioctl to toggle lazy write caching. Also, ISTR
that Trond had some patches at one point to let you micromanage the NFS
client caches. All of those are potentially useful, but without a
standard way to access them, it's hard to write applications that are
fs-agnostic.

For that reason, a hinting mechanism like posix_fadvise would seem to be
the best approach, IMO. The kernel could be free to ignore any of those
calls on filesystems where it's not implemented or not applicable.

-- 
Jeff Layton <jlayton@poochiereds.net>