Subject: Re: Extension of fsync_range() to permit forcing disk cache flushing
To: Bill Studenmund <wrstuden@NetBSD.org>
From: John Franklin <franklin@elfie.org>
List: tech-kern
Date: 12/16/2004 23:36:29
--Apple-Mail-3-396938069
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


On Dec 16, 2004, at 10:16 PM, Bill Studenmund wrote:

> On Fri, Dec 17, 2004 at 11:20:51AM +0900, YAMAMOTO Takashi wrote:
>> while you says "permanent storage" is device and environment=20
>> dependent,
>> why do you think flushing disk cache is always needed for your=20
>> application?
>
> My application needs to be able to ensure that data have reached the=20=

> disk
> under certain circumstances. The requirements implied by the SCSI
> SYNCHRONIZE CACHE command meet the requirements I wish to satisfy.=20
> Thus a
> clean way to issue a DIOCCACHESYNC ioctl is in order, and =
fsync_range()
> seems the best way.
>
> While I believe that few other applications will need this level of
> control, I think there may be a few. Thus I propose this change.

It seems reasonable to me to say that fsync() successfully writes it to=20=

the device, and the configuration of the device (write-back enabled or=20=

no) determines if it is already on the platters or waiting for the=20
train, so to speak.  Maybe that what I expect because I've been=20
tracking/involved with operating systems for my entire professional=20
career, and know too much.  Certainly, on some of the RAID controllers=20=

I've worked with, telling them to flush their considerable caches with=20=

every single fsync() would be murder on the throughput, and unnecessary=20=

for the RAID controllers with their own built-in battery systems.

Therefore, a way to force the write-back cache flush by way of an=20
fsync() flag is 100% reasonable.  The other two ways would be an ioctl=20=

or a new syscall.

jf
--=20
John Franklin
franklin@elfie.org
ICBM: 38=BA 56' 32.6"N 77=BA 24' 47.7"W Z+62m

--Apple-Mail-3-396938069
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBwmJN3khMMfgtqh0RAi/TAKCnUDal1ESkWEOBiDM0USWIgsAsggCgzy/r
WhshbZTPw3APOwlPLy42rLk=
=+C4K
-----END PGP SIGNATURE-----

--Apple-Mail-3-396938069--