--/9DWx/yDrRhgMJTb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 24, 2005 at 02:41:54PM +0100, Reinoud Zandijk wrote:
> Hiya Takashi,
>=20
> On Sat, Dec 24, 2005 at 08:35:22PM +0900, YAMAMOTO Takashi wrote:
> > > ftp://ftp.NetBSD.org/pub/NetBSD/misc/reinoud/src-diffs-udf.20051222.gz
> >=20
> > - it seems to do double-caching.  ie. at both of udf and block device.
> >   is it intended?
>=20
> Yes and no. For UDF it is better to use caching in udf since blocks can=
=20
> move around esp. on recordables; every disc write changes the location of=
=20
> the block so its easier to have it cached on the file's vnode on its=20
> logical block instead of a moving buffer on disc. Setting B_NOCACHE in th=
e=20
> buffers passed to the block device is prolly advisable yes.

Why is it easier?

UDF is not the first file system in our kernel to face this issue. LFS has=
=20
been dealing with it for over a decade. I think it would be VERY advisable=
=20
for UDF to do the exact same thing for a number of reasons:

1) LFS has worked out a huge number of the issues, so UDF can gain from=20
that experience.

2) It will be much easier for others to maintain the code if we only have=
=20
one way that we cope with block-shuffling file systems.

3) If UDF shows us we really need to fix an issue, LFS may gain from the=20
same changes.

Take care,

Bill

--/9DWx/yDrRhgMJTb
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDswSuWz+3JHUci9cRAq88AJ9pmxBDwLk8mG+SdzJ1sGmyJdJxewCgmWjF
PzMVgUx0Rmt7n4UaP5fT2Bw=
=v4xF
-----END PGP SIGNATURE-----

--/9DWx/yDrRhgMJTb--