On Fri, 2017-01-06 at 16:18 -0700, Andreas Dilger wrote: > On Jan 6, 2017, at 3:40 PM, David Howells <dhowells@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
