Subject: Re: wd, disk write cache, sync cache, and softdep.
To: Eric Haszlakiewicz <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 12/17/2004 10:48:09
Content-Type: text/plain; charset=us-ascii
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=
> > is that they impose ordering on any other write streams. Say there are =
> > other B1 and B2, and C1, C2, and C3. We don't care if it's A1, C1, B1, =
> > A2, A3, B2, C3 or A1, A2, A3, B1, B2, C1, C2, C3 or C1, A1, A2, B1, B2,=
> > A3, C2, C3. Or any other permutation, as long as the individual orders =
> > 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 =
> > ORDERED tags, we have at most one command being processed at once.
> 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=
> A2 if A3 has that set. =20
The code that issues A1 does not issue A2 until A1 is done. i.e. there is=
some thread waiting for the completion.
You understand FUA correctly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----