Subject: Re: wd, disk write cache, sync cache, and softdep.
To: Steven M. Bellovin <smb@research.att.com>
From: Daniel Carosone <dan@geek.com.au>
List: tech-kern
Date: 12/17/2004 07:18:25
--upHqgONuYbTeMWr5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 16, 2004 at 01:35:43PM -0500, Steven M. Bellovin wrote:
> In message <20041216182737.GA8856@netbsd.org>, Bill Studenmund writes:
> >
> >I think it'd be better to add a "Force Unit Access" attribute to writes,
> >and have them set when we need the write to bypass the cache. Among other
> >things, this action will directly map to SCSI command semantics (i.e. you
> >fix the problem for both SCSI and IDE drives).
>=20
> But under what conditions should higher layers set this flag?

Exactly; this is somewhat akin to my earlier idea of a barrier-type
operation that percolates through the softdep trees until it hits the
disk and triggers a 'sync point'.  It would be nice to have,
certainly, but non-trivial at best to implement.

The thing I liked about the completion queue idea is that it stays
etirely within the disk driver layer, and merely restores the disk
semantics that are assumed by all the upper layers: biodone buffers
are safely on stable storage.=20

The ideas are not incompatible, of course: arrival of one a write with
one of these force flags would be another condition to trigger a sync
cache.

I wasn't aware that there was a problem for SCSI disks, as Bill
suggests, by the way. I don't know if the filesystems are smart
enough, or have the interface to indicate, that a given write should
be done as a tagged or ordered command, or whether they just wait to
issue later writes until earlier ones are returned.

I assumed that they might issue sync writes, and that those might be
mapped by sd to ordered commands in this fashion, when I suggested
that this should be another completion criterion.  SCSI disks are
supposed to complete all outstanding tagged commands before each
ordered command, and we could emulate the same behaviour - all
assuming we get the information from the upper levels.

--
Dan.


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

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

iD8DBQFBwe2REAVxvV4N66cRAkJNAJwKAmxoF5D18iYHkKJFVafiFpyRkQCg0hZH
z1F+Cqd0Hs+XLEQ/CoojJnU=
=7KVJ
-----END PGP SIGNATURE-----

--upHqgONuYbTeMWr5--