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

On Mon, Sep 24, 2007 at 01:05:55AM -0400, der Mouse wrote:
> >>> I've been thinking of rewriting the name cache.  The changes I have
> >>> in mind would allow you to always get the path for a file.
> >> That sounds like a very drastic change [...]
> >> Will you also be providing replacements for existing filesystems?
> >> FFS, at least, has the "names are attached to links, not files"
> >> model wired fairly deeply into its on-disk data structures.
> > I'm sorry, but did you read the text you quoted?
>=20
> Yes.  Did *you* read the text *you* quoted?

Yes I did. Obviously not the same way you did.

> > Jason described a desire to re-write the name cache, which is an
> > in-kernel entity.  I fail to see how changing it translates into
> > changing (or needing to change) the on-disk format(s) of our file
> > system(s).
>=20
> Because arranging that files always have a path, and, what's more, have
> a "the path", is a very fundamental change to filesystem semantics, one
> that as far as I can see is incompatible with FFS on disk.  Regardless
> of the means by which this end is achieved.  (He can't possibly create
> the ability to "always get the path for a file" without, at the very
> least, breaking the ability to have files with no paths naming them, no
> matter what he is or isn't hacking on.)
>=20
> > There are a number of times (see the stuff that got this thread
> > started for instance) where we really need to be able to get a path
> > for a file.
>=20
> Well, I'm sorry, then you want something that is not very much like
> Unix.  Unix simply does not support that operation, and never has; it
> has always been possible to have files that have no paths at all that
> name them.
>=20
> > So we have a need now.  We have a developer expressing a desire to
> > address that need.  I suggest we wait for code to be offered before
> > reacting to details the not-yet-offered implementation may or may not
> > posess.
>=20
> Anything that satisfies the desire described - to always be able to get
> "the path" for a file - implies a very deep change to the filesystem
> semantics, and one that's incompatible with, at least, FFS - since in
> FFS files don't have names; rather, links to files have names, and
> there is no way quicker than searching the entire filesystem to find
> another link if the one you have is unlinked, nor does the concept of
> "the path" for a file make sense unless it happens to have exactly one
> link.
>=20
> Perhaps Jason meant "find a [not `the'] path for a file, provided it
> hasn't been unlinked or renamed yet".  But that's not what he wrote,
> and, based on what you write, it's not what you want, nor is it what he
> wants (to be pedantic, what you think he wants; I assume you're
> correct).  Perhaps Jason meant "find the path via which an open file
> was opened".  Perhaps Jason meant "find the path to a file in almost
> all cases, and we choose to let the facility using this break in the
> cases where it doesn't work".  But those aren't what he wrote either.
>=20
> What he *did* write seems to me to be fundamentally incompatible with
> Unix filesystem semantics, including the basic design of the on-disk
> data structures for what is probably our most popular filesystem.

Wow. You sure ran that into a corner.

I don't see the incompatability in what Jason said. I also don't take what=
=20
Jason said to be what you read into what he said. You read a lot of detail=
=20
into what he said and what you feel he didn't say. I didn't take his=20
comment as trying to be that precise, thus the level of detail you are=20
splitting hairs over wasn't on the table.

So how about we wait for actual code before trying to shoot it down?

Take care,

Bill

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

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

iD8DBQFG9/49Wz+3JHUci9cRAjYfAJwOj6XXljTPc0smv3vFPIzchKP7NgCdHa3A
nleVWqAeztMlabwSI0A3Crk=
=5aPu
-----END PGP SIGNATURE-----

--NQTVMVnDVuULnIzU--