Re: git: dae1713419a6 - main - zfs: merge openzfs/zfs@269b5dadc (master) into main

Hi,

śr., 17 lis 2021 o 12:48 Emmanuel Vadot <manu@bidouilliste.com> napisał(a):
>
> On Wed, 17 Nov 2021 11:43:18 +0000
> Tom Jones <thj@freebsd.org> wrote:
>
> > On Wed, Nov 17, 2021 at 10:24:11AM +0100, Marcin Wojtas wrote:
> > > Hi,
> > >
> > > Thank you for the update.
> > >
> > > ?r., 17 lis 2021 o 10:09 Martin Matuska <mm@freebsd.org> napisa?(a):
> > > >
> > > > The branch main has been updated by mm:
> > > >
> > > > URL: https://cgit.FreeBSD.org/src/commit/?id=dae1713419a669d4f6c7acddf81a21297c809741
> > > >
> > > > commit dae1713419a669d4f6c7acddf81a21297c809741
> > > > Merge: b6cbbcae40b4 269b5dadcfd1
> > > > Author:     Martin Matuska <mm@FreeBSD.org>
> > > > AuthorDate: 2021-11-17 08:35:14 +0000
> > > > Commit:     Martin Matuska <mm@FreeBSD.org>
> > > > CommitDate: 2021-11-17 08:39:40 +0000
> > > >
> > > >     zfs: merge openzfs/zfs@269b5dadc (master) into main
> > > >
> > > >     Notable upstream pull request merges:
> > > >       #12285 Introduce a tunable to exclude special class buffers from L2ARC
> > > >       #12689 Check l2cache vdevs pending list inside the vdev_inuse()
> > > >       #12735 Enable edonr in FreeBSD
> > > >       #12743 FreeBSD: fix world build after de198f2
> > > >       #12745 Restore dirty dnode detection logic
> > > >
> > > >     Obtained from:  OpenZFS
> > > >     OpenZFS commit: 269b5dadcfd1d5732cf763dddcd46009a332eae4
> > > >
> > >
> > > I have one question to make sure about the guidelines for future. I've
> > > been using ZFS on my arm64 machine for a while (a HEAD snapshot from
> > > ~July + custom newer kernels for development) - after trying the
> > > vanilla kernel after Nov 10 OpenZFS update I could no longer access
> > > the root partition (even after returning back to the kernel that had
> > > previously worked).
> > >
> > > I repeated the same thing with Nov 4 snapshot:
> > > - Install system with ZFS
> > > - Try kernel binary with updated OpenZFS - lose access to root partition.
> > >
> > > Is such behavior expected? If yes, is it recommended for the ZFS case
> > > to use kernel and the world only from the same baseline?
> > >
> > > Best regards,
> > > Marcin
> >
> > I don't know if this is related, but I just updated from the 4th
> > November snapshot to this commit and my zfs on root box can't mount
> > root.
> >
> > Annoyingly I haven't time to debug right now.
> >
> > - Tom
>
>  I had this problem recently and didn't had much time to debug but what
> I know is that it's related to recent addition of counter which adds
> some SYSINIT. I think that something in the zfs code isn't setup
> properly wrt order and breaks sometimes when SYSINIT are re-arranged by
> a new compile.
>  To confirm this just remove a few drivers from GENERIC that you don't
> use (I've removed stuff like nfs* which adds a lot of SYSINITs) and
> boot with debug.verbose_sysinit=1 to compare with a working kernel.

The problem observed in my setup is, that after booting the kernel
from top of main, there is no such thing as "working kernel" any more,
i.e. the damage seems to be permanent.

>  Also on my side typing '?' at mountroot listed the zfs pool so if it's
> the same for you that might be the same problem as mine (of course
> selecting the pool at mountroot didn't worked).

I tried all partitions listed with "?", but none worked. For the time
being I had to reinstall the system with UFS.

Best regards,
Marcin

>
>  Cheers,
>
> --
> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>