--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 17, 2004 at 01:03:41AM -0600, Eric Haszlakiewicz wrote:
> On Thu, Dec 16, 2004 at 04:10:39PM -0800, Bill Studenmund wrote:
> > While ORDERED commands are one way to do this, the big draw back with t=
hem=20
> > is that they impose ordering on any other write streams. Say there are =
two=20
> > other B1 and B2, and C1, C2, and C3. We don't care if it's A1, C1, B1, =
C2,=20
> > A2, A3, B2, C3 or A1, A2, A3, B1, B2, C1, C2, C3 or C1, A1, A2, B1, B2,=
=20
> > A3, C2, C3. Or any other permutation, as long as the individual orders =
are=20
> > respected. If we use FUA-type functionality, we can have up to three=20
> > commands outstanding at once, and we let the disk re-order them. If we =
use=20
> > ORDERED tags, we have at most one command being processed at once.
>=20
> 	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 before
> this command returns".  I don't see how that enforces an ordering on A1 a=
nd
> A2 if A3 has that set. =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.

You understand FUA correctly.

Take care,

Bill

--0F1p//8PRICkK4MW
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBwynpWz+3JHUci9cRAluIAJ9xTxeJek2+ndAD2wOGofSrSEAhTgCfYU2f
GIorTTSH8Ac4+saIL6uM2Mo=
=jyFt
-----END PGP SIGNATURE-----

--0F1p//8PRICkK4MW--