Re: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)
I've written a patch that implements zfs_vptocnp() using z_parent property. The new code should be 100% reliable for directories and "mostly" reliable for files (that is, when hardlinks across directories are not used). Could you please review / test it? https://reviews.freebsd.org/D8146 Thanks! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)
On 04/09/2016 17:51, Konstantin Belousov wrote: > 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. Yes, this is true. > 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. In fact, this is true for ZFS as well. While ZFS znodes have an attribute that specifies a (single) parent, it's obviously unreliable for files, because a file can be linked into multiple directories and then unlinked from a directory specified by the attribute. So, at the moment I do not have any good ideas on how to make this work. Maybe trying to use the parent attribute and failing when it's inconsistent would be good enough... -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)
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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
