On Wed, Jun 29, 2005 at 09:43:39AM +0900, YAMAMOTO Takashi wrote:
> > my point is that it does not seem correct to update timestamps as part of
> > cache-flushing.  whether or not the incorrect change is doable on a branch
> > is irrelevant.
> 
> my point was "do it when detecting dirtiness of pages".
> it happens to be the same place as cache-flushing in
> the current implementation.
> 
> > it seems better to have VOP_GETPAGES() update atime on VM_PROT_READ accesses
> > and update mtime on VM_PROT_WRITE accesses.  the only caller that doesn't
> > fit with this behaviour that has been mentioned so far is ufs_balloc_range().
> 
> updating mtime in VOP_GETPAGES means that you can see new mtime + old data.
> as pointed out, it has bad effects to eg. nfs cache coherency.

new mtime and old data is not a problem for NFS,
it's old mtime and new data that would be trouble.
but I see your point.


> > I meant that it makes a bit more sense for ufs_balloc_range() to call
> > VOP_GETPAGES() with VM_PROT_WRITE instead of VM_PROT_READ.
> 
> do you mean, letting VOP_GETPAGES allocate blocks rather than doing it in
> ufs_balloc_range?

no, though the change I was talking about would have had that unintended
side-effect.  I'll drop this idea for now.

-Chuck