Andriy Gapon
2016-Sep-04 08:24 UTC
Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)
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. Unfortunately, I have no clue how kern.proc.pathname works, so I would appreciate any hints at what filesystem operations I should look for potential problems. -- Andriy Gapon
Andriy Gapon
2016-Sep-04 13:11 UTC
Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)
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. I will think about a fix. Could you please file a bug report for this (if not already)? Sorry about the breakage. -- Andriy Gapon