From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-f177.google.com ([209.85.213.177]:33239 "EHLO mail-yb0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752959AbdATSOh (ORCPT ); Fri, 20 Jan 2017 13:14:37 -0500 Received: by mail-yb0-f177.google.com with SMTP id w194so65017821ybe.0 for ; Fri, 20 Jan 2017 10:14:37 -0800 (PST) Message-ID: <1484935685.2807.6.camel@redhat.com> Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Network filesystem cache management system call From: Jeff Layton To: David Howells Cc: "J. Bruce Fields" , linux-fsdevel@vger.kernel.org, lsf-pc@lists.linux-foundation.org, jaltman@auristor.com Date: Fri, 20 Jan 2017 13:08:05 -0500 In-Reply-To: <5514.1484934316@warthog.procyon.org.uk> References: <1484931193.2807.2.camel@redhat.com> <20170113171616.GG24709@fieldses.org> <12324.1483742446@warthog.procyon.org.uk> <14114.1484671351@warthog.procyon.org.uk> <5514.1484934316@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 Fri, 2017-01-20 at 17:45 +0000, David Howells wrote: > Jeff Layton 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