Subject: Re: /proc/${pid}/exe not working
To: Antti Kantee <>
From: Bill Studenmund <>
List: current-users
Date: 02/26/2007 12:54:51
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=
> > > What do people think?
> >=20
> > How would layerfs help? getcwd falls back on looking up ".." in a dir, =
> > that will fall through to the lower fs, which will find it in the cache.
> 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=
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=
levels to invalidate cache info.

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

Take care,


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

Version: GnuPG v1.4.3 (NetBSD)