> > > > > For mmap'ed accesses, probably. But I don't think this is a problem,
> > > > > because if we're faulting in a page via mmap(), we're reading the file,
> > > > > isn't it ?
> > > > 
> > > > i agree that it shouldn't be a problem, because it's
> > > > the pre-ubc behaviour, iirc.
> > > 
> > > Ha yes, so this should be restored too.
> > 
> > i'm not sure if it should.
> > i have not heard about any actual problem due to it.
> 
> Because peoples don't look at the access time that often. But it's usefull
> for diagnostics and statistics.

well, i have not heard any complaints about mtime either. (other than mine)
because mmap is rarely used, i guess.

> > due to VOP_GETPAGES called by ufs_balloc_range?
> 
> Yes, that's it. Testing !(ap->a_flags & PGO_PASTEOF) in addition to
> !(ap->a_access_type & VM_PROT_WRITE) makes the atime behaves as expected,
> from my tests.
> But we probably want a PGO_NOATIME (or maybe PGO_RMW, for read-modify-write)
> flag for this kind of access instead.

you might want to use VM_PROT_NONE for VOP_GETPAGES in ufs_balloc_range as
what it actually does is just holding pages without accessing them.
then you can check VM_PROT_READ, which is more straightforward than
VM_PROT_WRITE.

however, i still don't like the idea to update atime in VOP_GETPAGES.
it sounds like "update randomly" to me.
if we want to update atime for mmap, i prefer to do it when a file is mmap'ed.

YAMAMOTO Takashi