--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 01, 2007 at 03:01:44PM -0400, Thor Lancelot Simon wrote:
> On Sun, Jul 01, 2007 at 12:53:37PM -0400, Stephen M. Rumble wrote:
> > Hi all,
> >=20
> > I'm running into a strange behaviour while using bread(9) and am =20
> > unsure whether I misunderstand how it's supposed to behave, am running =
=20
> > into some sort of bug, or have otherwise misused the subsystem.
> >=20
> > The problem is that if I read one block from offset X, and then later =
=20
> > read more than one block from the same offset X, the overlapping block =
=20
> > contents are fine, but the rest is garbage. Here's a short code example:
>=20
> This is not how the buffer cache has ever worked.  The code basically
> assumes that, from the point of view of the caller of the buffer cache
> routines, the disk is divided into a fixed number of buffers of fixed siz=
e;
> so all I/Os to/from a given offset from the front of the disk must be done

Agreed. And back in the 1.2 timeframe, I actually encountered panics and=20
the like when using the "cooked" disk. Different i/o requests came in with=
=20
different sizes, and the buffer cache code paniced.

> with the same size.  When clustered filesystem I/O was done through the
> buffer cache, this was worked around in a fairly nasty way.
>=20
> I would not be displeased if you changed the buffer cache code so that
> this were no longer the case, and I doubt anyone else would either.

I doubt anyone would mind. However all the file systems we have get this=20
right, so not much would need it. Also, the main direction (I think) for=20
caching is UBC. All that's in the buffer cache is metadata.

Take care,

Bill

--k1lZvvs/B4yU6o8G
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFGiYwGWz+3JHUci9cRAgafAKCWxpqmoekur07LqxJb6n1F/aZgrgCeL5dz
TsvgVx8bl6EICp7kLJIIeoY=
=Yhd/
-----END PGP SIGNATURE-----

--k1lZvvs/B4yU6o8G--