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

[Jeff Layton <jlayton@redhat.com>]

On Tue, 2017-01-17 at 16:42 +0000, David Howells wrote:
> J. Bruce Fields <bfields@fieldses.org> wrote:
> 
> > > 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.
> > 
> > Do you have a summary of the AFS interface to give an idea what's
> > needed?
> 
> I have the pioctls listed here that I need to emulate:
> 
> 	https://www.infradead.org/~dhowells/kafs/user_interface.html
> 
> along with my thoughts on how to do that.
> 
> For cache wangling, I was thinking of something like:
> 
> 	fcachectl(int dirfd,
> 		  const char *pathname,
> 		  unsigned atflags,
> 		  const char *cmd,
> 		  char *result,
> 		  size_t *result_len);
> 

I think it might be more useful to wire posix_fadvise into the
filesystem drivers somehow. A hinting interface really seems like the
right approach here, given the differences between different
filesystems.
 
> The relevant pioctls are:
> 
>  (*) VIOCGETCACHEPARMS
> 
>      Get the size of the cache.
> 

Global or per-inode cache?

>  (*) VIOCSETCACHESIZE
> 
>      Set the cache size.
> 
>  (*) VIOCFLUSH
> 
>      Invalidate the cached information for an object, both the inode/dentry
>      structs and anything in the local cache.
> 

Maybe POSIX_FADV_DONTNEED ?

>  (*) VIOCFLUSHCB
> 
>      Invalidate any callbacks/leases outstanding on an object.  This might
>      make more sense to be done via the same mechanism as lease/lock
>      management.
> 

Well...just because we have a delegation or layout on NFS, that doesn't
mean we'll have any sort of client VFS-layer lease.

I guess you could use this on NFS to force the client to drop a
delegation or layout? That could be useful.


>  (*) VIOC_FLUSHVOLUME
> 
>      Flush all cached state for a volume, both from RAM and local disk cache
>      as far as possible.  Files that are open aren't necessarily affected.
> 

Maybe POSIX_FADV_DONTNEED on the mountpoint?

>  (*) VIOC_FLUSHALL
> 
>      FLush all cached state for all volumes.
> 

How would you implement that in a generic way? Suppose I have a mix of
AFS and NFS mountpoints and issue this via some mechanism. Is
everything going to drop their caches?

Might want to punt on this one or do it with a private, AFS-only ioctl.


>  (*) VIOCPREFETCH
> 
>      Prefetch a file into the cache.
> 

POSIX_FADV_WILLNEED ?

> So, maybe:
> 
> 	fcachectl(AT_FDCWD,
> 		  "/afs/user/dhowells",
> 		  0,
> 		  "flush volume",
> 		  NULL, NULL);
> 
> to flush an AFS volume containing my home directory.
> 
> Note that doing this by fcntl() or ioctl() has potential difficulties as it
> would have to work on non-file objects such as device files or symlinks.
> 

Does AFS allow remote access to devices a'la CIFS?

Could we allow posix_fadvise on O_PATH opens? For symlinks there is
always O_NOFOLLOW.

> Other functions that this could be used for are cache pinning and
> fixup/integration should we ever want disconnected operation.
> 

Yeah, a lot of possibilities there.

-- 
Jeff Layton <jlayton@redhat.com>