On Wed, Jun 29, 2005 at 09:42:46AM +0900, YAMAMOTO Takashi wrote:
> > currently, once a page is first faulted and the pmap-level mapping is created,
> > it can be modified again indefinitely without the kernel knowing and thus
> > without mtime being updated.  if this is a problem, then we could change
> > things so that making a clean page dirty again will cause another fault
> > to give us a chance to update mtime again.  we'll need that same refault-
> > on-redirty logic to do the fsync() optimizations that were discussed
> > some time back, so once we have that then we could also call back into
> > the fs to update mtime if we want.
> > 
> > -Chuck
> 
> have you decided to do fsync optimization in the way which needs
> refault-on-redirty?

it does seem like the best approach.  if it's done properly,
the overhead should be negligable.


> an alternative is not to care much about pages dirtied via mmap
> as it isn't required by any standards afaik.

the susv3 description of fsync() says:

  The fsync() function shall request that all data for the open file
  descriptor named by fildes is to be transferred to the storage device
  associated with the file described by fildes. The nature of the transfer
  is implementation-defined. The fsync() function shall not return until
  the system has completed that action or until an error is detected.


so the question would be whether data put into a file via mappings is
part of "all data" for that file.  it doesn't seem reasonable to say
that it isn't.  so I'd much prefer that fsync() operate on pages
dirtied via mappings as well as those dirtied via write().  even if
the standard did not require it, it seems like a better implementation
anyway.

-Chuck