On Tue, Jun 28, 2005 at 05:42:03PM +0900, YAMAMOTO Takashi wrote:
> > > > 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.
> > 
> > You mean, mtime isn't updated for mmaped files either ? That's much more
> > annoying, because backup tools relies on mtime for incremental backups.
> 
> yes.  i think i've filed a PR about it sometime ago.
> 
> > > 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.
> > 
> > And do it again when it's unmapped then.
> 
> why on unmap?

Well, we agree that we for mmaped file we can't update atime on each read.
Then it depend if we want to record the first possible read, or the last
possible. I think the last posssible would be more accurate for long-running
processes.
But I still believe updating it in VOP_GETPAGES() would give even more accurate
informations for long-running processes.

> 
> > And the same for mtime, I guess.
> 
> for mtime, update on munmap might make sense.

For backup tools to properly work, I think we have to do it each time a write
is flushed to disk. This can be done in VOP_PUTPAGES(), isn't it ?

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