--2fHTh5uZTiUOsy+g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 03, 2004 at 11:34:38PM +0900, YAMAMOTO Takashi wrote:
> hi,
>=20
> > > i'd say the comments are wrong, however, ok, i have no particular pro=
blem
> > > with your suggested way.  (ie. change the MAKEENTRY's behaviour)
> >=20
> > Thank you. Also put something in there somewhere about what we should d=
o=20
> > about negaitve caching & DELETE or RENAME for the remote fs case. I'd=
=20
> > suggest turning the cnp->cn_nameiop !=3D CREATE into cnp->cn_nameiop =
=3D=3D=20
> > LOOKUP, but the point's still up for discussion if you want something=
=20
> > else.
>=20
> after some more thoughts, i think it's better to leave the decision to
> each filesystems as they should know their own characteristics better.
> how about the attached diffs?  (ufs and nfs only.)

Everything I've seen and heard so far in this thread indicates that our
leaf file systems will fall into one of two camps, local and remote. You
are very right that cache_lookup() is very local-fs-centric, your initial
point in this thread. And it should change.

However nothing I've seen either in this thread or in my knowledge of the
different file systems indicates different local file systems will need
different (local) policy, nor that different remote file systems will need
different (remote) policy.

By my count, ffs, lfs, ext2fs, adosfs, filecorefs, msdosfs, and ntfs are
our leaf file systems. I believe they will all want the same behavior as
each other when it comes to how they use the cache. When we get UDF and=20
hfs file systems, they will want this same behavior. I realize I'm being=20
optimistic about ntfs writability. Counting that lfs and ffs use the same=
=20
lookup code, we now have 5 local leaf lookup routines that can delete=20
entries. If we get busy with new file systems, that can go to 8.

On the remote fs side of things, we have nfs, smbfs, and coda. Adding afs,=
=20
which folks keep trying to get working (and which I want to encourage)=20
makes 4 remote file systems.

My objection to your suggestion of having each fs roll its own is that we=
=20
have five routines doing the same thing (local fs's) and four routines all=
=20
doing the same thing (remote fs's) different from the first thing. We have=
=20
nine routines working out two behaviors.

It sounds both cleaner and easier to maintain to just have those routines
either call one of two common routines, or call one common routine that
supports the two behaviors.

Is there something I'm missing?

Take care,

Bill

--2fHTh5uZTiUOsy+g
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAcL9/Wz+3JHUci9cRAuD2AJ9r+d5utDSc7FMxpu73SGcW5s4TYACdGtQf
PQQzZA1uKYE5dIxc7S9iWv8=
=O6Ak
-----END PGP SIGNATURE-----

--2fHTh5uZTiUOsy+g--