--PPYy/fEw/8QCHSq3
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?
>=20
> it does seem like the best approach.  if it's done properly,
> the overhead should be negligable.
>=20
>=20
> > an alternative is not to care much about pages dirtied via mmap
> > as it isn't required by any standards afaik.
>=20
> the susv3 description of fsync() says:
>=20
>   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.
>=20
>=20
> 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=
=20
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,

Bill

--PPYy/fEw/8QCHSq3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCwtDDWz+3JHUci9cRArRNAJ9t21Pl5te4nQZolppigaRn1O188QCfRW2C
1w3JwSwN0xEYcf4VQM3Cdic=
=MSIB
-----END PGP SIGNATURE-----

--PPYy/fEw/8QCHSq3--