Re: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

[Andriy Gapon]

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)

[Andriy Gapon]

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)

[Konstantin Belousov]

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)

[Andriy Gapon]

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)

[Andriy Gapon]

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"

Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

[Frederic Chardon]

2016-08-25 13:29 GMT+02:00 Frederic Chardon :
>
> Le 23 août 2016 20:24, "Frederic Chardon"  a
> écrit :
>>
>> 2016-08-23 19:35 GMT+02:00 Frederic Chardon :
>> > 2016-08-23 9:35 GMT+02:00 Konstantin Belousov :
>> >> On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote:
>> >>> Le 20 ao??t 2016 22:03, "Frederic Chardon"
>> >>>  a
>> >>> ??crit :
>> >>> >
>> >>> > Hi
>> >>> >
>> >>> > I see a strange interaction between zfs on root and
>> >>> > kern.proc.pathname
>> >>> > on my laptop. Whenever I try to use gcore it fails with:
>> >>> > gcore 1023
>> >>> > gcore: kern.proc.pathname failure
>> >>> >
>> >>> > However, gcore /usr/local/bin/zsh 1023 is working properly.
>> >>> >
>> >>> > I made some tests booting from usb stick (fresh installworld, no
>> >>> > src.conf, no make.conf, GENERIC kernel)
>> >>> > What works: having / on ufs and importing a zfs pool later on.
>> >>> > What doesn't: having / on zfs, whatever the settings for checksum,
>> >>> > compression, or normalization.
>> >>> >
>> >>> > Both 11-stable and 12-current behave this way. Current from may-june
>> >>> > worked properly.
>> >>> > adb, chromium and virtualbox as well stopped working at
>> >>> > approximately
>> >>> > the same time, however I don't know if it is linked ("truss -f adb
>> >>> > start-server" shows that garbage is passed to execl after forking).
>> >>> >
>> >>> > Any idea what's going on? Does anybody else see this?
>> >>> >
>> >>> > Thanks!
>> >>>
>> >>> Nobody else have this problem? I reinstalled the system from scratch
>> >>> and
>> >>> still gcore fails with the same error, even in single user mode.
>> >>
>> >> Do you have a property on your root fs which forces it to ignore case
>> >> in
>> >> the file names ?
>> >
>> > No. I do have normalization set to formC though. I observed the same
>> > behavior with the property unset (in fact, with no property set to
>> > anything but default as well).
>> > If I boot from usb stick and import the pool afterwards it works
>> > properly.
>> >
>> > zpool get all zbase
>> > NAME   PROPERTY   VALUE
>> > SOURCE
>> > zbase  size   9,94G  -
>> > zbase  capacity   43%-
>> > zbase  altroot-
>> > default
>> > zbase  health ONLINE -
>> > zbase  guid   8964242380523899513
>> > default
>> > zbase  version-
>> > default
>> > zbase  bootfs zbase/bootenv/11-STABLE
>> > local
>> > zbase  delegation on
>> > default
>> > zbase  autoreplaceoff
>> > default
>> > zbase  cachefile  -
>> > default
>> > zbase  failmode   wait
>> > default
>> > zbase  listsnapshots  off
>> > default
>> > zbase  autoexpand off
>> > default
>> > zbase  dedupditto 0
>> > default
>> > zbase  dedupratio 1.00x  -
>> > zbase  free   5,65G  -
>> > zbase  allocated  4,29G  -
>> > zbase  readonly   off-
>> > zbase  comment-
>> > default
>> > zbase  expandsize -  -
>> > zbase  freeing0
>> > default
>> > zbase  fragmentation  41%-
>> > zbase  leaked 0
>> > default
>> > zbase  feature@async_destroy  enabled
>> > local
>> > zbase  feature@empty_bpobjactive
>> > local
>> > zbase  feature@lz4_compress   active
>> > local
>> > zbase  feature@multi_vdev_crash_dump  enabled
>> > local
>> > zbase  feature@spacemap_histogram active
>> > local
>> > zbase  feature@enabled_txgactive
>> > local
>> > zbase  feature@hole_birth active
>> > local
>> > zbase  feature@extensible_dataset enabled
>> > local
>> > zbase  feature@embedded_data  active
>> > local
>> > zbase  feature@bookmarks  enabled
>> > local
>> > zbase  feature@filesystem_limits  enabled
>> > local
>> > zbase  feature@large_blocks   enabled
>> > local
>> > zbase  feature@sha512 enabled
>> > local
>> > zbase  feature@skein  enabled
>> > local
>> >
>> >
>> > zfs get all zbase/bootenv/11-STABLE
>> > NAME PROPERTY  VALUE
>> > SOURCE
>> > zbase/bootenv/11-STABLE  type  filesystem
>> > -
>> > zbase/bootenv/11-STABLE  creation  sam. août 20 13:07 2016
>> > -
>> > zbase/bootenv/11-STABLE  used  4,23G
>> > -
>> >