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 <chardon....@gmail.com>:
>
> Le 23 août 2016 20:24, "Frederic Chardon" <chardon....@gmail.com> a
> écrit :
>>
>> 2016-08-23 19:35 GMT+02:00 Frederic Chardon <chardon....@gmail.com>:
>> > 2016-08-23 9:35 GMT+02:00 Konstantin Belousov <kost...@gmail.com>:
>> >> On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote:
>> >>> Le 20 ao??t 2016 22:03, "Frederic Chardon"
>> >>> <chardon....@gmail.com> 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 autoreplace off
>> > 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 freeing 0
>> > default
>> > zbase fragmentation 41% -
>> > zbase leaked 0
>> > default
>> > zbase feature@async_destroy enabled
>> > local
>> > zbase feature@empty_bpobj active
>> > local
>> > zbase feature@lz4_compress active
>> > local
>> > zbase feature@multi_vdev_crash_dump enabled
>> > local
>> > zbase feature@spacemap_histogram active
>> > local
>> > zbase feature@enabled_txg active
>> > 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
>> > -
>> > zbase/bootenv/11-STABLE available 5,34G
>> > -
>> > zbase/bootenv/11-STABLE referenced 2,72G
>> > -
>> > zbase/bootenv/11-STABLE compressratio 1.97x
>> > -
>> > zbase/bootenv/11-STABLE mounted yes
>> > -
>> > zbase/bootenv/11-STABLE quota none
>> > default
>> > zbase/bootenv/11-STABLE reservation none
>> > default
>> > zbase/bootenv/11-STABLE recordsize 128K
>> > default
>> > zbase/bootenv/11-STABLE mountpoint /
>> > local
>> > zbase/bootenv/11-STABLE sharenfs off
>> > default
>> > zbase/bootenv/11-STABLE checksum sha256
>> > inherited from zbase
>> > zbase/bootenv/11-STABLE compression lz4
>> > inherited from zbase
>> > zbase/bootenv/11-STABLE atime off
>> > inherited from zbase
>> > zbase/bootenv/11-STABLE devices on
>> > default
>> > zbase/bootenv/11-STABLE exec on
>> > default
>> > zbase/bootenv/11-STABLE setuid on
>> > default
>> > zbase/bootenv/11-STABLE readonly off
>> > default
>> > zbase/bootenv/11-STABLE jailed off
>> > default
>> > zbase/bootenv/11-STABLE snapdir hidden
>> > default
>> > zbase/bootenv/11-STABLE aclmode discard
>> > default
>> > zbase/bootenv/11-STABLE aclinherit restricted
>> > default
>> > zbase/bootenv/11-STABLE canmount on
>> > local
>> > zbase/bootenv/11-STABLE xattr off
>> > temporary
>> > zbase/bootenv/11-STABLE copies 1
>> > default
>> > zbase/bootenv/11-STABLE version 5
>> > -
>> > zbase/bootenv/11-STABLE utf8only on
>> > -
>> > zbase/bootenv/11-STABLE normalization formC
>> > -
>> > zbase/bootenv/11-STABLE casesensitivity sensitive
>> > -
>> > zbase/bootenv/11-STABLE vscan off
>> > default
>> > zbase/bootenv/11-STABLE nbmand off
>> > default
>> > zbase/bootenv/11-STABLE sharesmb off
>> > default
>> > zbase/bootenv/11-STABLE refquota none
>> > default
>> > zbase/bootenv/11-STABLE refreservation none
>> > default
>> > zbase/bootenv/11-STABLE primarycache all
>> > default
>> > zbase/bootenv/11-STABLE secondarycache all
>> > default
>> > zbase/bootenv/11-STABLE usedbysnapshots 1,52G
>> > -
>> > zbase/bootenv/11-STABLE usedbydataset 2,72G
>> > -
>> > zbase/bootenv/11-STABLE usedbychildren 0
>> > -
>> > zbase/bootenv/11-STABLE usedbyrefreservation 0
>> > -
>> > zbase/bootenv/11-STABLE logbias latency
>> > default
>> > zbase/bootenv/11-STABLE dedup off
>> > default
>> > zbase/bootenv/11-STABLE mlslabel
>> > -
>> > zbase/bootenv/11-STABLE sync disabled
>> > inherited from zbase
>> > zbase/bootenv/11-STABLE refcompressratio 1.96x
>> > -
>> > zbase/bootenv/11-STABLE written 37,6M
>> > -
>> > zbase/bootenv/11-STABLE logicalused 7,82G
>> > -
>> > zbase/bootenv/11-STABLE logicalreferenced 4,95G
>> > -
>> > zbase/bootenv/11-STABLE volmode default
>> > default
>> > zbase/bootenv/11-STABLE filesystem_limit none
>> > default
>> > zbase/bootenv/11-STABLE snapshot_limit none
>> > default
>> > zbase/bootenv/11-STABLE filesystem_count none
>> > default
>> > zbase/bootenv/11-STABLE snapshot_count none
>> > default
>> > zbase/bootenv/11-STABLE redundant_metadata all
>> > default
>>
>> I meant: "if I boot from a _UFS_ usb stick" of course. The FreeBSD
>> installation img for example.
>
> 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.
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[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

[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.

[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.

[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

[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!