Subject: Re: letting userland issue FUA writes
To: Joachim K?nig-Baltes <joachim.koenig-baltes@emesgarten.de>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 03/17/2006 08:39:04
--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 17, 2006 at 09:43:04AM +0100, Joachim K?nig-Baltes wrote:
> Bill Studenmund wrote:
>=20
> > The problem is it's not the exact semantics for what I want. I want
> > FUA down to the array. Among other things, you can have an array that
> > has a Battery-Backed-up-Unit and will write FUA'd writes to the BBU
> > and just pass non-FUA through to the disks. Waiting for after the call
> > can't change that behavior.  :-(
>=20
> Yes, understood.

[snip]

> and later, Bill Studenmund wrote:
> > That was my thought. Or actually some write_with_flag and
> > writev_with_flag syscalls. One flag could fold in pwrite vs normal
> > write, and another flag could fold in FUA.
>=20
>=20
> Or add a "const void *buf" argument to fsync_range, not as general as
> with pwritev or adding syscalls, but perhaps less intrusive on the
> interfaces.

I am unclear how this parameter would help. fsync_range() has a flags=20
parameter, so what does the buf pointer do?

Also, I feel like I'm repeating myself, but adding FUA to fsync_range() is=
=20
too late to get "write this to disk with FUA" semantics; if the pages have=
=20
already been written to disk, there's no way to go back and add FUA to=20
those writes. Given that some arrays handle (or can be configured to=20
handle) FUA different from non-FUA, we need it on those writes.

Also, with FUA, you really want write-through caching as opposed to
write-back.

Take care,

Bill

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

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

iD8DBQFEGuYoWz+3JHUci9cRAlrvAJ4lpIWhbkOW3zbA/T9C5Tt65R/zIgCdHExE
7mYVVQIsqzsS8jIlIrUzsEg=
=awwd
-----END PGP SIGNATURE-----

--G4iJoqBmSsgzjUCe--