Re: ZFS errors with two HEX numbers.

Curious - on my 13-STABLE box that I haven't bothered updating in a
minute...

[root@fbsd13bed ~]# uname -a;zpool version;
FreeBSD fbsd13bed 13.0-STABLE FreeBSD 13.0-STABLE #1
stable/13-n247014-e8e5d75e6a96: Mon Aug 30 16:24:56 EDT 2021
root@fbsd13bed:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
zfs-2.1.99-426_g70bf547a9
zfs-kmod-2.1.99-426_g70bf547a9
[root@fbsd13bed ~]# zdb -dd zroot/0x97 | head
Dataset zroot/usr/src [ZPL], ID 151, cr_txg 17, 2.92G, 94231 objects

    ZIL header: claim_txg 0, claim_blk_seq 0, claim_lr_seq 0 replay_seq 0,
flags 0x0


    Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
         0    6   128K    16K  29.3M     512   112M   41.01  DMU dnode
        -1    1   128K    512      0     512    512  100.00  ZFS
user/group/project used
        -2    1   128K    512      0     512    512  100.00  ZFS
user/group/project used
        -3    1   128K    512      0     512    512  100.00  ZFS
user/group/project used
[root@fbsd13bed ~]# zdb -dd zroot/0x98 | head
failed to hold objset 152: Invalid argument
zdb: can't open 'zroot/0x98': Invalid argument

So what version of FBSD and ZFS are you running on?

- Rich

On Sun, Sep 26, 2021 at 5:31 PM Zaphod Beeblebrox <zbeeble@gmail.com> wrote:

> Entertaining.  That (even with only two --> zdb -dd vr1/0x57b2) gives ...
> core dump.  SIGSEGV in strlen.  Dereferencing a NULL.
>
> (gdb) bt
> #0  strlen (str=0xd <error: Cannot access memory at address 0xd>) at
> /usr/src/lib/libc/string/strlen.c:101
> #1  0x0000000800f6ea60 in __vfprintf (fp=<optimized out>,
> locale=0x80102eed8 <__xlocale_global_locale>,
>     fmt0=<optimized out>, ap=<optimized out>) at
> /usr/src/lib/libc/stdio/vfprintf.c:854
> #2  0x0000000800f6b8df in snprintf (str=0x801644400 "", n=<optimized out>,
> fmt=0x8009ad9b9 "%s/%s")
>     at /usr/src/lib/libc/stdio/snprintf.c:74
> #3  0x0000000800a58b76 in zfs_file_open (path=path@entry=0x801644000
> "/etc/zfs/zpool.cache", flags=<optimized out>,
>     flags@entry=0, mode=<optimized out>, mode@entry=0, fpp=fpp@entry
> =0x7fffffe58788)
>     at /usr/src/sys/contrib/openzfs/lib/libzpool/kernel.c:1075
> #4  0x0000000800b3e622 in spa_config_load () at
> /usr/src/sys/contrib/openzfs/module/zfs/spa_config.c:101
> #5  0x0000000800b47b39 in spa_init (mode=mode@entry=SPA_MODE_READ)
>     at /usr/src/sys/contrib/openzfs/module/zfs/spa_misc.c:2393
> #6  0x0000000800a586ae in kernel_init (mode=1) at
> /usr/src/sys/contrib/openzfs/lib/libzpool/kernel.c:844
> #7  0x0000000000405984 in ?? ()
> #8  0x00000000004052df in ?? ()
> #9  0x0000000800637008 in ?? ()
> #10 0x0000000000000000 in ?? ()
>
> On Sun, Sep 26, 2021 at 12:53 AM Rich <rincebrain@gmail.com> wrote:
>
>> I don't have a testpool handy to confirm it, but I would expect you to
>> be able to do something like
>> zdb -ddddd [pool]/[objsetid in hex] [objectid in hex]
>> e.g.
>> zdb -ddddd vr1/0x57b2 0x73ab46
>>
>> Or failing that, drop the object id (and then probably some of the -d,
>> that gets real verbose).
>>
>> - Rich
>>
>> On Sun, Sep 26, 2021 at 12:27 AM Zaphod Beeblebrox <zbeeble@gmail.com>
>> wrote:
>> >
>> > How do I find which snapshot it's in?
>> >
>> > On Sat, Sep 25, 2021 at 6:01 PM Miroslav Lachman <000.fbsd@quip.cz>
>> wrote:
>> >
>> > >
>> > >
>> > > I have seen this in the past. It was corruption on some deleted file
>> > > preserved on snapshot. Once I deleted snapshots this error
>> disappeared.
>> > >
>> > > [...]
>> > >
>> > > Miroslav Lachman
>> > >
>>
>