--Qz2CZ664xQdCRdPu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 17, 2004 at 01:56:46PM -0600, Eric Haszlakiewicz wrote:
> On Fri, Dec 17, 2004 at 10:48:09AM -0800, Bill Studenmund wrote:
> > On Fri, Dec 17, 2004 at 01:03:41AM -0600, Eric Haszlakiewicz wrote:
> > > 	huh?  I'm not understanding what FUA means then.  I had assumed that
> > > setting FUA on a write means "this write must actually be written bef=
ore
> > > this command returns".  I don't see how that enforces an ordering on =
A1 and
> > > A2 if A3 has that set. =20
> >=20
> > The code that issues A1 does not issue A2 until A1 is done. i.e. there =
is=20
> > some thread waiting for the completion.
>=20
> 	How can it know A1 is done if there's no way to tell the drive to
> flush its cache?  A possible timeline I see is:

You assert FUA for write A1.

> send A1, drive says OK,
> send A2, drive says OK,
> send A3+FUA, drive writes A3 (due to FUA), drive says OK,
> drive writes A2, drive writes A1.

You assert FUA for EACH write.

Take care,

Bill

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

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

iD8DBQFBw4mNWz+3JHUci9cRAtgoAKCUSNshtzcXBg5l48gk8aOuoDSE6gCfVPZB
BMQMvYuYfu9uv/oogIFPH84=
=Y0i7
-----END PGP SIGNATURE-----

--Qz2CZ664xQdCRdPu--