Subject: Re: fsync optimization (Re: kern/25279: NFS read doesn't update atime)
To: Chuck Silvers <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 06/29/2005 09:48:03
Content-Type: text/plain; charset=us-ascii
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:
> > 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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----