Subject: Re: Overlapping bread(9) behaviour
To: None <rumble@ephemeral.org>
From: Bill Stouder-Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 07/03/2007 10:00:39
--hYooF8G/hrfVAmum
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 03, 2007 at 11:55:17AM -0400, Stephen M. Rumble wrote:
> Quoting Thor Lancelot Simon <tls@rek.tjls.com>:
>=20
> >On Tue, Jul 03, 2007 at 10:18:55AM -0400, Stephen M. Rumble wrote:
> >>
> >>In any event, I'd either like to fix this so it behaves as expected,
> >
> >What is "as expected"?  It works the way the Unix buffer cache always ha=
s.
>=20
> "As expected" is my interpretation of what bread(9) says. It makes no =20
> mention that what I was previously attempting to do is invalid. The =20
> system also makes no attempt to assert that it's being used properly =20
> in this regard. I think that a note in the manual and an assertion =20
> would be appropriate.

I agree we should improve the documentation.

> >>A few related questions: If the buffer cache expects fixed-sized
> >>buffers, does that mean for some filesystems there could be a 124-byte
> >>struct buf for each block of cached data? Also, do we not have any
> >>filesystems with extents where this sort of thing would have cropped
> >>up before?
> >
> >You understand that actual file data is not cached through the buffer
> >cache, yes?  If EFS is doing so, EFS is buggy.  The buffer cache is only
> >used for metadata now -- the page cache handles all else.
>=20
> No, I did not understand this very well. I should update the =20
> documentation to express this.
>=20
> This clarifies things a fair bit. I was wondering how UBC could work =20
> if the routines in vfs_bio.c pre-allocated a fixed amount of buffer =20
> memory. I was also confused as to how mmaped operations maintained =20
> consistency with the buffer cache.
>=20
> EFS does not use the buffer cache for VREG. It does, however, for VDIR =
=20
> and VLNK. I think this is appropriate. Kindly correct me if I'm wrong.

Should be fine.

Take care,

Bill

--hYooF8G/hrfVAmum
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFGioC3Wz+3JHUci9cRArBYAJ9YQTXqpzIH6rnz/qY0fqIwu/MmGACePTUi
0O4rMhW6KMXJNoJEiqnrfP0=
=yX9G
-----END PGP SIGNATURE-----

--hYooF8G/hrfVAmum--