Weikuan Yu <wkyuwk@xxxxxxxxx> wrote:
> As I'am looking more into the cachefs code, I am quite a bit confused about
> how cachefs could be useful for the type of netfs' that use page cache but
> not local disk caches. Suppose in the read case, the part I do not catch is
> as follows. When a page is first read from server and marked up-to-date, it
> is then stored in the cachefs. By the time it is to be read again, we want
> to read it from cachefs assuming local disk access is faster than going for
> remote server.
> My questions here are as follows:
>
> a) if the page in the cachefs is still valid (up-to-date), would it still be
> in the page-cache? If so, reading from cachefs would not be efficient then.
The answer is maybe. The page cache is in RAM, but the RAM is only so big and
is generally subject to losing its contents when the box is rebooted.
If you read more data than will fit in the page cache, the VM will start
discarding pages from the page cache.
Note, however, that when the VM kicks pages out of the page cache that doesn't
mean they automatically get evicted from the disk cache also. The two caches
are separate entities.
> b) Is it possible that the page is already evicted from pagecache, but it is
> still in the cachefs? In that case, the page can then be read back from
> cachefs and stored back into page cache if possible.
That's exactly it yes. What would be the point in a disk cache if we only held
pages there that were also in RAM? Apart from, perhaps, power management...
> Also in this case, when trying to read from pagecache or cachefs, is it
> guaranteed that the cached file page is not out-of-date w.r.t the copy at
> the server side.
That's something only the netfs can deal with. All the disk cache can do is
store sufficient auxiliary data on behalf of the netfs to permit the netfs to
make this decision, and provide a way of requesting eviction of old data from
the cache.
For instance, with AFS, there's a 64-bit data version number that is
incremented each time a change is made to the file. kAFS checks this against
the one stored in the auxiliary data in the cache. The odds are in favour of
the disk holding your cache wearing out before the number wraps.
However, with NFS, there's no such useful trick. Instead we have to make use
of things like file size and file times - but there's always a slim
possibility that we'll get it wrong. There's nothing we can do about that;
it's inherent in the NFS network protocol.
> I might have just asked some naive questions. Please bear with me. But they
> puzzle me quite a bit. I appreciate anybody who would like to help clear my
> doubts here.
Sure, that's what we're here for.
One way to look at this whole system is as a stack of caches:
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| | | | | | | Page | | FS | | |
| CPU |--->| L1 |--->| L2 |--->| Cache |--->| Cache |--->| NFS |
| | | | | | | | | | | |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
Each cache has a certain granularity and each cache may retain some of the
data read through it. In actual fact the picture is more messy as the netfs
looks aside to FS-Cache rather than reading through it; it's just that that
way of doing things fits better with the address space operations we have now.
We could add more address space operations, build FS-Cache into the VFS/VM and
make the caching more seemless for netfs writers, but I'm not sure it'd be
permitted. Remember: looking in a cache slows things down, even if the cache
is actually absent; would you want to do that on _all_ page accesses? Even
those going to local disk anyway? I can see arguments either way.
David
