Subject: Re: Extension of fsync_range() to permit forcing disk cache flushing
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 12/16/2004 19:16:17
--ZrCu0B0FMx3UnjE2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 17, 2004 at 11:20:51AM +0900, YAMAMOTO Takashi wrote:
> hi,
>=20
> > Also, you're implicitly assuming that disks don't fail. If an admin has
> > taken steps, either in configuration or product choice (good UPS or RAID
> > box w/ battery backup for cache), to ensure that writing to the disk dr=
ive
> > is as good as writing to the media, why penalize him or her by forcing
> > cache flushing. And since disks fail (even in RAID), all we have to do =
is
> > make sure that the cache failure probability is less than the disk drive
> > failure probability, and then the cache doesn't matter.
>=20
> while you says "permanent storage" is device and environment dependent,
> why do you think flushing disk cache is always needed for your applicatio=
n?

My application needs to be able to ensure that data have reached the disk
under certain circumstances. The requirements implied by the SCSI
SYNCHRONIZE CACHE command meet the requirements I wish to satisfy. Thus a=
=20
clean way to issue a DIOCCACHESYNC ioctl is in order, and fsync_range()=20
seems the best way.

While I believe that few other applications will need this level of=20
control, I think there may be a few. Thus I propose this change.

Take care,

Bill

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

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

iD8DBQFBwk+BWz+3JHUci9cRAmwFAJ9Ue9wwfAd6GoNypUsLJrLuky0zcgCfa87v
Ujm3AQspQnaN8d3dYsuBojs=
=y1bA
-----END PGP SIGNATURE-----

--ZrCu0B0FMx3UnjE2--