Subject: Re: fsync optimization (Re: kern/25279: NFS read doesn't update atime)
To: Chuck Silvers <>
From: Bill Studenmund <>
List: tech-kern
Date: 06/29/2005 09:48:03
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 29, 2005 at 09:40:27AM -0700, Chuck Silvers wrote:
> On Wed, Jun 29, 2005 at 09:42:46AM +0900, YAMAMOTO Takashi wrote:
> >=20
> > 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.

I agree. I think that pages dirtied by mmap should count as well as pages=
dirtied by write(). Besides the fact I can't really see why they=20
shouldn't, it means that syncing operations need only look to see if the=20
pages are dirty, regardless of the reason for dirtying.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)