Date: Sun, 4 Sep 2016 17:51:03 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: Frederic Chardon <chardon.frederic@gmail.com>, freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs) Message-ID: <20160904145103.GD83214@kib.kiev.ua> In-Reply-To: <b7e6ace7-ec52-4bdb-0185-ef6bcddb371e@FreeBSD.org> References: <CAMODbknGPaXR3=v-caacyigP5MdDgc9DKhAq=FMWh5=r7GzoDA@mail.gmail.com> <1aebfb2b-5df6-abe0-686f-b170fdaef510@FreeBSD.org> <b7e6ace7-ec52-4bdb-0185-ef6bcddb371e@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 04, 2016 at 04:11:39PM +0300, Andriy Gapon wrote: > On 04/09/2016 11:24, Andriy Gapon wrote: > > On 27/08/2016 22:09, Frederic Chardon wrote: > >>> Anybody is able to reproduce this behavior or is it a local problem? > >> Reverting 303970 solves this issue. gcore and adb works again, and I > >> can start the vboxnet service. > >> I recreated my boot pool with no properties defined, just to be sure. > > > > I can not reproduce this issue here. > > I was not trying hard enough. I've just reproduced the problem using a > non-default normalization property. The issue is that 303970 disabled the use > of VFS name cache when any name "mangling" (normalization, case-insensitivity) > is enabled. And apparently I misunderstood how vop_stdvptocnp() works. So, > right now zfs_vptocnp() is broken when its argument is a non-directory vnode. > That fact is masked when the name cache is used and is exposed otherwise. It is only masked when name cache has an entry for the vnode. So sometimes vn_fullpath() should be broken even if no normalization is applied. OTOH, classic filesystems like UFS do not have any other means to translate non-directory inode to name and parent at all, except the namecache hint.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160904145103.GD83214>