Jeff Layton <jlayton@xxxxxxxxxx> 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. > > (*) 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. > > (*) 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. 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. :-) > 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. David -- 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
