On Tue, Jun 28, 2005 at 09:05:11AM -0700, Chuck Silvers wrote:
> > Yes, but this requires an interface change in the vnode op, which may not
> > be doable on the existing branches. In addition, this code doens't exist
> > yet.
> 
> 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.

It is if the "correct" fix can't be pulled up to branches.

> 
> 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().

Ha, I didn't see it this way.

> 
> 
> > > > - after fixing ufs_balloc_range() to not use VM_PROT_READ, test for
> > > >   VM_PROT_READ in VOP_GETPAGE() to see if we should update the atime or not
> > > 
> > > is sorta makes more sense to use VM_PROT_WRITE here instead of VM_PROT_READ,
> > 
> > In a previous mail YAMAMOTO Takashi said it would be more straitforward to
> > test VM_PROT_READ here instead of VM_PROT_WRITE (once ufs_balloc_range() uses
> > VM_PROT_NONE).
> 
> 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.

OK, I'll see what I can do with that.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--