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--