Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > (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! > > (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. > > + 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. > > + 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 -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-cachefs