Subject: Re: wd, disk write cache, sync cache, and softdep.
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 12/20/2004 09:48:04
--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 18, 2004 at 09:33:43AM +0100, Manuel Bouyer wrote:
> On Sat, Dec 18, 2004 at 09:07:56AM +0100, Manuel Bouyer wrote:
> > The FUA bit should for the media acess, so in this case the cache flush
> > for A3, and any commands queued before A3 if A3 is queued with
> > ordered queue tag + FUA.
>=20
> Hum, FUA and simple/ordered tasks are defined in 2 different SCSI drafts
> (SCSI block command and SCSI Architecture model), so things are not that
> clear. We may need to set the FUA bit on all 3 commands to make sure A1 a=
nd A2
> reach the platters before A3.

Yes, FUA needs to be set for each command. FUA applies to only one=20
command, the one in which it is set. It has the same effect as turning the=
=20
one write command into a write followed by a synchronize cache that covers=
=20
just the write area of the one command.

It solves the problem we are (were) discussing about metadata updates.=20
Given a sequence of metadata update A1, A2, A3 (or any sequence of writes=
=20
where subsequent writes must not appear before a preceeding one), the=20
natural thing to do is add code to issue the first one, wait for=20
completion, then issue the next one. As noted, with a write cache on, we=20
get who-knows-what on disk (in terms of ordering). With FUA set on each=20
write, though, we won't get the completion response until the write has=20
actually hit permanent storage. So our simple little ordering code now=20
works right.

Also, we do not impact other writes in progress at that time. So we could=
=20
have tens or 100s of megabytes in write cache (obviously not a cheep disk=
=20
for those #s) and we let the firmware continue to write it as it sees fit.

Take care,

Bill

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

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

iD8DBQFBxxBTWz+3JHUci9cRAs1vAJ9eiY68OvNVFeDP2GYdsi0Ip/TShgCffkdN
0dv0N1GfrwbT5gA2eEJ5y7M=
=29hP
-----END PGP SIGNATURE-----

--PNTmBPCT7hxwcZjr--