Subject: Re: RFC: VOP_LOOKUP() speedup
To: None <>
From: Bill Studenmund <>
List: tech-kern
Date: 05/10/2004 16:25:44
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.
> 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=
> 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=
> 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,


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

Version: GnuPG v1.2.3 (NetBSD)