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

[Jeff Layton <jlayton@redhat.com>]

On Fri, 2017-01-20 at 17:45 +0000, David Howells wrote:
> Jeff Layton <jlayton@redhat.com> wrote:
> 
> > 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 main reason I'm against using an fd-taking interface is that the object to
> be affected might not be a regular file and could even be mounted over.
> 

How would you disambiguate the mounted-over case with a path-based
interface?

> > >  (*) VIOCGETCACHEPARMS
> > > 
> > >      Get the size of the cache.
> > > 
> > 
> > Global or per-inode cache?
> 
> I think this would have to be whatever cache the target inode is lurking
> within.  fscache permits multiple caches on a system.
> 

Ok, but does this tell you "how big is this entire cache?" or "how much
cache does this inode currently consume" ? Both 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?
> 
> Ugh.  No.  How would you differentiate flushing just the mountpoint or the
> root dir from flushing the volume?  Also, you cannot open the mountpoint
> object if it is mounted over.
> 

Good point.

I don't know...this kind of thing might be better suited to a sysfs-
style interface, honestly. Anything where you're dealing at the level
of an entire fs doesn't benefit much from a per-inode syscall
interface. That said, that could get messy once you start dealing with
namespaces and such.

> Also POSIX_FADV_DONTNEED is a hint that an application no longer needs the
> data and is not a specifically a command to flush that data.
> 
> > >  (*) 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.
> 
> Might be worth making it AFS-only.  Possibly it would make sense to implement
> it in userspace using VIOC_FLUSHVOLUME and iterating over /proc/mounts, but
> that then begs the question of whether this should be affected by namespaces.
> 
> > POSIX_FADV_WILLNEED ?
> 
> Perhaps.
> 
> > Does AFS allow remote access to devices a'la CIFS?
> 
> No. :-)
> 

I'm not sure I get why it's terribly useful to manipulate the cache on
a symlink or device file itself. There's generally not much cached
anyway, right (generally nothing more than a page anyway).

> > Could we allow posix_fadvise on O_PATH opens?  For symlinks there is always
> > O_NOFOLLOW.
> 
> Maybe.  Al?
> 
> This doesn't work for mounted-over mountpoints, however.  I guess we could add
> AT_NO_FOLLOW_MOUNTS to get the basalmost mountpoint.
> 

Yeah, perhaps.
-- 
Jeff Layton <jlayton@redhat.com>