Re: [RFC PATCH 02/53] netfs: Track the fpos above which the server has no data

Jeff Layton [off-list ref] wrote:

quoted

 (7) If stored data is culled from the local cache, we must set zero_point
     above that if the data also got written to the server.

When you say culled here, it sounds like you're just throwing out the
dirty cache without writing the data back. That shouldn't be allowed
though, so I must be misunderstanding what you mean here. Can you
explain?

I meant fscache specifically.  Too many caches - and some of them with the
same names!

quoted

 (8) If dirty data is written back to the server, but not the local cache,
     we must set zero_point above that.

How do you write back without writing to the local cache? I'm guessing
this means you're doing a non-buffered write?

I meant fscache.  fscache can decline to honour a request to store data.

quoted

+		if (size != i_size) {
+			truncate_pagecache(&vnode->netfs.inode, size);
+			netfs_resize_file(&vnode->netfs, size);
+			fscache_resize_cookie(afs_vnode_cache(vnode), size);
+		}

Isn't this an existing bug? AFS is not setting remote_i_size in the
setattr path currently? I think this probably ought to be done in a
preliminary AFS patch.

It is being set.  afs_apply_status() sets it.  This is called by
afs_vnode_commit_status() which is called from afs_setattr_success().  The
value isn't updated until we get the return status from the server that
includes the new value.

quoted

+	loff_t			zero_point;	/* Size after which we assume there's no data
+						 * on the server */

While I understand the concept, I'm not yet sure I understand how this
new value will be used. It might be better to merge this patch in with
the patch that adds the first user of this data.

I'll consider it.  At least it might make sense to move them adjacent to each
other in the series.

David