From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-f173.google.com ([209.85.213.173]:32968 "EHLO mail-yb0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751026AbdATQym (ORCPT ); Fri, 20 Jan 2017 11:54:42 -0500 Received: by mail-yb0-f173.google.com with SMTP id w194so61734024ybe.0 for ; Fri, 20 Jan 2017 08:53:21 -0800 (PST) Message-ID: <1484931193.2807.2.camel@redhat.com> Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Network filesystem cache management system call From: Jeff Layton To: David Howells , "J. Bruce Fields" Cc: linux-fsdevel@vger.kernel.org, lsf-pc@lists.linux-foundation.org, jaltman@auristor.com Date: Fri, 20 Jan 2017 11:53:13 -0500 In-Reply-To: <14114.1484671351@warthog.procyon.org.uk> References: <20170113171616.GG24709@fieldses.org> <12324.1483742446@warthog.procyon.org.uk> <14114.1484671351@warthog.procyon.org.uk> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, 2017-01-17 at 16:42 +0000, David Howells wrote: > J. Bruce Fields 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