--wtO4+9l+3RkKLqxD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 16, 2004 at 09:50:39AM +0100, Pavel Cahyna wrote:
> Thanks for your analysis. I thought I'm alone in thinking that having
> softdeps carefully ordering writes and the disk carefully destroying that
> ordering, especially when the write cache is on by default, is a serious
> bug in NetBSD.

Not so much a bug as a deployment choice (including the choice of
hardware to purchase), but never mind the semantics.

> > Conditions for issuing a synccache in this fashion might include:
>=20
> What about adding the condition that the total size of all unsynced write
> requests is greater than the size of on-disk cache?

This might be a good one, if there's a standard way to query the disk
for this information at probe time; i'm not sure there is. Having
something that has to be set by the admin with dkctl or atactl or
whatever seems.. suboptimal, but if there are magic numbers they
should be tunable and this would be another such.

In any case, writes in the completion queue may already actually be on
the platters (we just don't know for sure until we sync), especially
if they've been forced out by later writes as the cache fills.  When
we reach this point, writes actually take a while to complete, and so
the write queue may start growing, and we'll need some other criteria
than just the first to get the completion queue cleared.

I'd like to keep the list as short and simple as possible, but a
collection of candidates is an important start - it will take some
careful thought and perhaps some experiment to select the best ones in
practice.

--
Dan.

--wtO4+9l+3RkKLqxD
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBwU4nEAVxvV4N66cRAvGhAKCJoeJtc6jV/sTOJ66ZzSEQ5BGssQCg8MF/
kgaq0SRy4JsNdUsvkvunYlk=
=T5M1
-----END PGP SIGNATURE-----

--wtO4+9l+3RkKLqxD--