Subject: Re: RFC: VOP_LOOKUP() speedup
To: None <tech-kern@netbsd.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 05/10/2004 16:25:44
--1ccMZA6j1vT5UqiK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 06, 2004 at 07:49:19AM +0200, Reinoud Zandijk wrote:
> On Wed, May 05, 2004 at 09:12:28AM -0700, Bill Studenmund wrote:
> > > So this is correct? i dont miss out a thing?
> >=20
> > With the second cache =3D=3D block cache, yes, I think that's right.
>=20
> Problem with UDF is that i can't use the device's block cache for CDs/DVDs
> unless i could get it to use it only as a kind of read-`cache' that *neve=
r*
> just writes back at its own will if i tell it so. To implement CD-RW and
> DVD-RW, UDFs has to write with a fixed packet length; with CD-R and
> DVD+R/DVD-R its obvious that i can only write in one `direction' i.e. =20
> ordered; what happeneds with write-errors i dont even want to know ;) How=
=20
> does the rest of the filingsystems deal with this situation?

Well, nothing in the kernel caching code will write back anything (from=20
either the buffer or vm caches) unless you mark it dirty.

As for writing in only one direction, talk to the LFS folks.

> Now it would propably advisable if i could claim/release the
> `minicache'-lines dynamically from KVA; problem then is offcource still
> when to release them... i dont want udfs to be a memory hogger ... the
> current `minicache' is about 1Mb allready allthough it could be made
> smaller.

Take care,

Bill

--1ccMZA6j1vT5UqiK
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAoA94Wz+3JHUci9cRAuMpAJ9gL1X78V8q4n86V/OFGuCVbaDadgCcD83E
lWqLFDMZG0GeJZdU1LgKgnw=
=vyGD
-----END PGP SIGNATURE-----

--1ccMZA6j1vT5UqiK--