On 06/09/2016 07:09 PM, Dave Howorth wrote:
What cacheing can the kernel do? The filesystem is multi-hosted (at least in possibility) yes? So surely the kernel has to go right back to the filesystem every time to make sure it gets current state information.
No. If user A searches for a file (be it to read, write or just stat()) and the kernel reads the inode for that file, it caches it, LRU. If later, user B opens that file to write to it, so modifying the size and time, or perhaps, instead, does a chmod(), the kernel has that inode in its cache once again. It will sync the inode to disk to preserve the metastructure, but its till in the cache. So when user A comes to whatever or stat the file again, its still in the cache, the updated version is in the cache. IIR inode caching was in the non-networked UNIX V7 or the 1970s. I don't know if it was V6, I'd have to go to the library and find a copy of Lyons. This holds true if the file system is NFS mounted by multiple hosts, the caching is by the host the mounts the disk, not the ones that do the NFS mounting. The clients may be configured to cache the results of the NFS 'getattr()' call, but it will be for a very short time. You might look at the 'slabtop' command. I see that the ext4FS has additional inode caching, and so too, it seems does Btrfs. This is news to me :-/ SUN later introduced pathname caching as well. I saw the code for that once, but it was years ago and I don't recall the algorithm. At https://www.kernel.org/doc/Documentation/sysctl/vm.txt you can read the entry for vfs_cache_pressure. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org