Subject: Re: /proc/${pid}/exe not working
To: Antti Kantee <pooka@cs.hut.fi>
From: Bill Studenmund <wrstuden@netbsd.org>
List: current-users
Date: 02/26/2007 12:54:51
--OwLcNYc0lM97+oe1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 26, 2007 at 10:15:50PM +0200, Antti Kantee wrote:
> On Mon Feb 26 2007 at 11:56:04 -0800, Bill Studenmund wrote:
> > > That's because cwd can do real getcwd if the entry is not found in the
> > > cache - directories always have a unique parent.  Other types of file
> > > system nodes, however, lack this luxury (think hardlinks).
> > >=20
> > > As a hack to fix a hack, maybe we can add layerfs support the name ca=
che?
> > > What do people think?
> >=20
> > How would layerfs help? getcwd falls back on looking up ".." in a dir, =
and=20
> > that will fall through to the lower fs, which will find it in the cache.
>=20
> No, the problem is that nullfs doesn't enter anything into the name
> cache and we can't do getcwd for regular files.  So my thinking was
> telling cache_revlookup that if it doesn't succeed for layered vnodes,
> it could consult lower layer nodes also for revlookup information.
> Of course it would get information from the wrong layer back unless
> it would do a linear scan of the upper layer to find the correct vnode
> (or do we have a nicer way of doing lower->upper lookup?).

Part of my confusion is that I didn't see any layered file systems in the=
=20
original problem. ;-)

As for caching, the reason we don't, at present, have cache entries in=20
layers is that we don't have a mechanism for the lower level to tell upper=
=20
levels to invalidate cache info.

I've batted ideas around w/ folks, but we've never pulled the trigger on=20
it.

Take care,

Bill

--OwLcNYc0lM97+oe1
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD4DBQFF40kbWz+3JHUci9cRAhd3AKCOrEZbuEW+95kTLSb+okuOEggXoQCY7Dl3
oXtNE2wjLt70raHBuPDSWw==
=s9ZJ
-----END PGP SIGNATURE-----

--OwLcNYc0lM97+oe1--