On Thu, Jun 30, 2005 at 12:13:27PM +0900, YAMAMOTO Takashi wrote:
> > > 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.
> 
> i've heard an argument, something like this:
> 	it's "all data for the open file descriptor",
> 	not "all data for the file associated with the descriptor".

I've never heard of any implementation which associates data with a file
descriptor rather than a file.  certainly our implementation does not.
that argument seems a little out of touch with reality.


> anyway, both approaches have their own pros and cons.
> i have no strong affinity.

ok, then let's stick with the current approach.

-Chuck