From nobody Sun Aug 11 16:56:12 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WhkLx6VmJz5TCby for ; Sun, 11 Aug 2024 16:56:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WhkLx41khz4GFf for ; Sun, 11 Aug 2024 16:56:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oo1-xc2d.google.com with SMTP id 006d021491bc7-5d608060241so2243003eaf.1 for ; Sun, 11 Aug 2024 09:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1723395384; x=1724000184; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0vo0u2hHN9G1ytXY5FYH6CXgYjUSwtB4TU2OqJsaSqk=; b=EI4of/Qrhs94mn39MlQcEOFxlaH+NJMhbSqC2eOmeL7g5yI2LWN3An3HOD4lTg2N8d 4Mj33N7Uv4MR3B15rQFYcHqQZIEUU5Iw/QrtOEG6HLYTZrdXbphB2ODII37oaU+nJtvC gnZVcYgKhFj5MeEq58+RZTQw+T6KoLzm7fCIdJFpeI3HXAYiVWUpqGcUvg5J4njIkzxd FnF/eMHAbHOuGcNjbz403CInBj/1ig0kIITIHiH/9RCsOgQ3d3DEo9sQvjn2SWV63zsg UHnnUpokQlYx0IxbrW4w02CKfZGxZPf0CIPFndnGOj7p74mQAzWXOI3jtoonoLRKKrTi VyVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723395384; x=1724000184; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0vo0u2hHN9G1ytXY5FYH6CXgYjUSwtB4TU2OqJsaSqk=; b=o9dZqz7icrctRxinV/dK2D+ADfSYgVIGp4C2sGlvutcNjct86s3A2BMgtgwM46iN3Y g8itmJGqbM1PNHO8r2KPQn84+Tnw7mIIwLQUpm2a7SaJ5hUJ/Nvncd0ZNxZKzi8RSUYV mK87K309W6zQmcTMQ85IzFOWm+xKBqDiadcc4yPFnP5PSVOuYNskbKEzfAxjqzY5RfPI XswbUCdVRmbCqMkB/oCpbIfa0V7qpzJpRzbaCSSIaGTJ4t/TRfpl5SoqXvG0was7nZn7 nA4uOGJARtvsvAVZaGqYoYaUiXzv0yhWh0XWIN/12vjUQ/jWCEyMAjtjkXQ4tyt7WTWQ EsgA== X-Gm-Message-State: AOJu0YzuSwJAMspWl14zn8Hd43wdyD+3lSRUUX27BMI6XpiJZDwhndPo UhAqTQGK7VBhPoiW7TNy39FQfOR+MeSmvmH2HyCIoUtA9gE2eBkvgXpfas9rcycpuFBvrzI5Kex 6WbQAHgqhM7ub/IF+rcERQM3TdpUWdoWEQE/ThY+a4vreLqYb X-Google-Smtp-Source: AGHT+IF37+fwiKm+0cOX5EWjKZ1TqThMYNgrxpFoKlyln0ouGbei9muhDg1zDo1wkQ7HNA8A0RlkJLS13xLdvAQoD+Q= X-Received: by 2002:a05:6358:5f1a:b0:1ac:f3df:3bda with SMTP id e5c5f4694b2df-1b176edf716mr1078388555d.1.1723395384009; Sun, 11 Aug 2024 09:56:24 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <20240811021506.04996DB@slippy.cwsent.com> <54076f5e-cd6d-40d6-b4b7-495cf8e67572@blastwave.org> <20240811134119.91DD57F@slippy.cwsent.com> <47f96d89-e1d1-43a8-b456-7b30240d1fad@blastwave.org> In-Reply-To: <47f96d89-e1d1-43a8-b456-7b30240d1fad@blastwave.org> From: Warner Losh Date: Sun, 11 Aug 2024 10:56:12 -0600 Message-ID: Subject: Re: git: ce4dcb97ca43 - main - zfs: merge openzfs/zfs@9c56b8ec7 To: Dennis Clarke Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000ac0338061f6b4144" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WhkLx41khz4GFf --000000000000ac0338061f6b4144 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Aug 11, 2024, 10:29=E2=80=AFAM Dennis Clarke wrote: > On 8/11/24 09:41, Cy Schubert wrote: > > In message <54076f5e-cd6d-40d6-b4b7-495cf8e67572@blastwave.org>, Dennis > > Clarke > > writes: > >> On 8/10/24 22:15, Cy Schubert wrote: > >>> In message , Mark > Millard > >>> write > >>> s: > >> > >>>> =3DE2=3D80=3DA2 [2:12 PM]Flox: getting this error in ZFS since= recent > =3D > >>>> update in HEAD > >>>> =3DE2=3D80=3DA2 [2:12 PM]Flox: > >>>> sysctl_warn_reuse: can't re-use a leaf =3D > >>>> (kstat.zfs.zroot.dataset.objset-0x204.zil_itx_metaslab_slog_alloc)! > >>>> pid 58 (zpool) is attempting to use unsafe AIO requests - not loggin= g > =3D > >>>> anymore > >>>> > >>>> =3DE2=3D80=3DA2 [2:13 PM]Flox: > >>>> FreeBSD fbsd15.localdomain 15.0-CURRENT FreeBSD 15.0-CURRENT #0 =3D > >>>> main-aea9dba46b: Sat Aug 10 16:48:02 EDT 2024 =3D > >>>> mike@fbsd15.localdomain:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NOD= EBUG > =3D > >>>> amd64 > >>> > >>> Yeah. I'm getting tons of these on all my machines as well. > >>> > >>> sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.cwsys.dataset.objset-0x2c > >> c > >>> d.zil_itx_metaslab_slog_alloc)! > >>> > >>> > >> > >> > >> Yep. Seems to be a real thing just pouring out all over the console he= re > >> too : > >> > >> > >> sysctl_warn_reuse: can't re-use a leaf > >> (kstat.zfs.t1.dataset.objset-0x4b0.zil_itx_metaslab_slog_alloc)! > > > > This only happens on import: when the system boots and when any pools a= re > > imported later on. > > > > Sadly .. nope ... that is not the case : > > triton# uptime > 4:27PM up 11:33, 2 users, load averages: 2.76, 0.93, 0.37 > triton# > triton# sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x6508.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x6508.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x6508.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x5e74.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x5e74.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x5e74.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x6603.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x6603.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x6603.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x5e7c.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x5e7c.zil_itx_metaslab_slog_alloc)! > sysctl_warn_reuse: can't re-use a leaf > (kstat.zfs.t1.dataset.objset-0x5e7c.zil_itx_metaslab_slog_alloc)! > > So seems to be a thing when the machine is running and doing things like > a poudriere bulk build etc etc .. > Poudriere does a lot of ZFS dataset manipulation, so this isn't surprising. Warner I have not seen it when the machine is just twiddling its thumbs > pondering an existential crisis. Yet. > > >> > >> > >> Just a tad uncomfortable to see. > > > > Uncomfortable but harmless. > > > > In that case let's make it go away .. mmmkay ? > > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken > > > --000000000000ac0338061f6b4144 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Aug 11, 2024, 10:29=E2=80=AFAM Dennis Clarke &= lt;dclarke@blastwave.org> w= rote:
On 8/11/24 09:41, Cy Schubert= wrote:
> In message <54076f5e-cd6d-40d6-b4b7= -495cf8e67572@blastwave.org>, Dennis
> Clarke
> writes:
>> On 8/10/24 22:15, Cy Schubert wrote:
>>> In message <FB135AEB-1B52-42F3-= 93F4-2B1B67FC1395@yahoo.com>, Mark Millard
>>> write
>>> s:
>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=3DE2=3D80=3DA2 [2:12 PM]Flox: g= etting this error in ZFS since recent =3D
>>>> update in HEAD
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=3DE2=3D80=3DA2 [2:12 PM]Flox: >>>> sysctl_warn_reuse: can't re-use a leaf =3D
>>>> (kstat.zfs.zroot.dataset.objset-0x204.zil_itx_metaslab_slo= g_alloc)!
>>>> pid 58 (zpool) is attempting to use unsafe AIO requests - = not logging =3D
>>>> anymore
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=3DE2=3D80=3DA2 [2:13 PM]Flox: >>>> FreeBSD fbsd15.localdomain 15.0-CURRENT FreeBSD 15.0-CURRE= NT #0 =3D
>>>> main-aea9dba46b: Sat Aug 10 16:48:02 EDT 2024 =3D
>>>> mike@fbsd15.localdomain:/usr/obj/usr/src/amd64.amd64/sys/G= ENERIC-NODEBUG =3D
>>>> amd64
>>>
>>> Yeah. I'm getting tons of these on all my machines as well= .
>>>
>>> sysctl_warn_reuse: can't re-use a leaf (kstat.zfs.cwsys.da= taset.objset-0x2c
>> c
>>> d.zil_itx_metaslab_slog_alloc)!
>>>
>>>
>>
>>
>> Yep. Seems to be a real thing just pouring out all over the consol= e here
>> too :
>>
>>
>> sysctl_warn_reuse: can't re-use a leaf
>> (kstat.zfs.t1.dataset.objset-0x4b0.zil_itx_metaslab_slog_alloc)! >
> This only happens on import: when the system boots and when any pools = are
> imported later on.
>

Sadly .. nope ... that is not the case :

triton# uptime
=C2=A0 4:27PM=C2=A0 up 11:33, 2 users, load averages: 2.76, 0.93, 0.37
triton#
triton# sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x6508.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x6508.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x6508.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x5e74.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x5e74.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x5e74.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x6603.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x6603.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x6603.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x5e7c.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x5e7c.zil_itx_metaslab_slog_alloc)!
sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.t1.dataset.objset-0x5e7c.zil_itx_metaslab_slog_alloc)!

So seems to be a thing when the machine is running and doing things like a poudriere bulk build etc etc ..

Poudriere does a lot of ZFS dataset manipu= lation, so this isn't surprising.=C2=A0

Warner

I have not seen it when the machine is just twiddling its thumbs
=C2=A0 pondering an existential crisis. Yet.

>>
>>
>> Just a tad uncomfortable to see.
>
> Uncomfortable but harmless.
>

In that case let's make it go away .. mmmkay ?

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken


--000000000000ac0338061f6b4144--