From nobody Mon Nov 24 03:08:33 2025 X-Original-To: hackers@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 4dF9kp5QBqz6Hv4w for ; Mon, 24 Nov 2025 03:08:34 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dF9kp4XQLz3RB0; Mon, 24 Nov 2025 03:08:34 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763953714; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3r74m3tQZxqlotVPHMBUYueJ0VhKQeAkNd3bYx72/Qg=; b=TpolzHMs876KkmGGXblUsOU2+8ONPu6g6vDXgNipIgZ4rOX0UCtbb9mureR8Offs3DAARR D15LppwcDMb+xWQ0kMb3JFKjIee9xl46q3JrB3kvAJ7BbgG8YrTgIkBfVG611LzeueksMT kIFaBTyKDqQIrfWREfq1yf22UW5xmmPjNBlCHG6+sv+OBWn1ErtzMUyNovJzk+4C4pCpx6 i3apwwg9UFo705yXZmgjAdaT1LCe3L3B4AsecZHuNT7pSXEflmCpXvOPT0OuW/VYI+PQeX RaMBKk4kYB3G4v6Rx1l6dH/CW9/7EltrEZusmXRZxGbm2s5fNIyti/IfCj6aMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763953714; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3r74m3tQZxqlotVPHMBUYueJ0VhKQeAkNd3bYx72/Qg=; b=IqFveDJJUc0vXhf0o008RqKuZrLgUNoFw8uHkcvkbgMaa/IJAWFL1/hIhko/mHbuDkETo9 xAfQs+tWmFRuMXPLTXshD2+4fqzheFBDfu7eEIr41RfG28ux8jeP2OCLiMEzxAlTqKGngw tBlbFjQVl5iIvEupqL4iOosIBrsdIPvKyjD+9zRpciyyW+qtGCbQYpQwMCnWiyU8xqxRRx 3IQTUgRX3B/kIM0fHPxITaFHv8Hq1/LWxOE89r5dHUuB68YgHQmx4KV3WXH8XbLqmDFy1w 0lkN20d6mJwnwsMe+fFhHwbvla6uw08Gr5bf4dKbv9VXiTZm8Jje5cw/CZT9jQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763953714; a=rsa-sha256; cv=none; b=nNu5oYEdvO15lhSz9vQdoXR/OnS8yLr7bs9nqrT5HcYVfPflaa9/ObOChqBu/ITACNETIH Dy6oufNW6vfo9jjMjgIAJwJMkmj/5LSWxt3rMG7IazQolVzrwmcLcH5ZsjNU9kWpHnyR6d /GXjmcfXsb8+9pnZB5SlCuAbRllMZrLx3x9ddgIJCeo1pVNKjAtU5VSCTKyc61cv7IM+bB t6hk4QChu57bhdCVfh4xeoWJoahDGRdhUYTZN11X1zh3zuNxta02COJCGOQLwYAqY4k3+A PJpVhQ2gVZ+TNNSIx9D919X04FBJEFY9xgi6Re1UcbmbTNO3KIbKZfl1HcWSsw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (2a01cb0585090500922e16fffef1acef.ipv6.abo.wanadoo.fr [IPv6:2a01:cb05:8509:500:922e:16ff:fef1:acef]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dF9kp2sK5zN1Z; Mon, 24 Nov 2025 03:08:34 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 17E6C8B9CE; Mon, 24 Nov 2025 04:08:33 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ankush Mondal Cc: hackers@freebsd.org Subject: Re: How to get started with FreeBSD dev In-Reply-To: (Ankush Mondal's message of "Mon, 17 Nov 2025 18:16:57 +0530") References: User-Agent: Gnus/5.13 (Gnus v5.13) Date: Mon, 24 Nov 2025 04:08:33 +0100 Message-ID: <86ldjw86vi.fsf@ltc.des.dev> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ankush Mondal writes: > [...] Could you guide me on how to get started with FreeBSD > development? Assuming you've already installed FreeBSD and figured out how to build and install it from source, and you know C, here are a few recent bug reports that should be approachable by a beginner: https://bugs.freebsd.org/290710 https://bugs.freebsd.org/290711 https://bugs.freebsd.org/291027 https://bugs.freebsd.org/291141 DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Mon Nov 24 06:37:10 2025 X-Original-To: hackers@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 4dFGMr5vd5z6J9mX for ; Mon, 24 Nov 2025 06:37:28 +0000 (UTC) (envelope-from ankushmondal1y2t@gmail.com) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 4dFGMr2sdtz3sRj for ; Mon, 24 Nov 2025 06:37:28 +0000 (UTC) (envelope-from ankushmondal1y2t@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-bdcae553883so261204a12.0 for ; Sun, 23 Nov 2025 22:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763966242; x=1764571042; 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=CBjeFijsQwu7tRw2dmWuJw0ukwbQRcIe6aLI4YhsMmI=; b=XFkmIR65uRfH7wS/CErs2TqBObKwMASUlFSow1M3erCqs4Pl5d/cbswdRvCaaojhNr gV4oiYiwNOwq7PjMes09XdWQ1LNhP3a8+a6xsI6eoFmqXL9ib7MF57cGVTr1Pb4T/XTF XzbHiKNPh9RgQAVtyOx/BnZIln3boSp0uFTTnMcF05DHEwGqSc+ARCjk5WuCl+APxbQF Onzsdtxtwv7NUmoGOwoUqTM1Cx8pSADqD7ZrI0pqNrpoWjcMEBoHsa7FyqILAgII5OCX 4dixbi+fOjET/YVbC06J2JLqnTO6QPCFfS8unoSJbACRA9P3jcavb8/CxPG8CwVJAb5f qz9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763966242; x=1764571042; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CBjeFijsQwu7tRw2dmWuJw0ukwbQRcIe6aLI4YhsMmI=; b=UPRqmynoZvAVDh30Ta4nrcXx8Q1SlK2S8S9ziVrKblLupX/8Z5nWg5wOT8tCJN7Azf 0eDSILO1IfggW8wajLP3QP0gXzutHSNlWgaojwHJfMkgOVtTNGwaz9QgEBFh9Zs7bcfy og04Tn+/vH2wEKui4XZALX+VSOdKBMi3AqVakUc+Hle0e5PUcsZlOG3APZ/I3EUSkRBo VChCtmlhCxvhdlTXtBMeKg2pOi1HH2SaetI43yU1mJfJv2R6R6uPYFIIf/2QfQ1Adl9V M+3oTMvEE5q834Uv37syM3xt61QnU/1CJDU5vbAoqrno5wKLqYSyjLThjaYmImG/9oJA nosA== X-Gm-Message-State: AOJu0Yz/LFP7DWLyQK9bwktS9g3Rgzp59wqHflE18ZIyVEeWQ9B4Qa06 OdpjTPUKk9T3CVVJSWUYmWJ+MfcadVOthYhtE4Z0D5fI0/Gd+t+c9GhLEl/ZTHOpV4SHUdCC64V mZ+ZBbnikBKdKqWW2sGgNJ04NAevDhO8BKVHA X-Gm-Gg: ASbGncs6R/Den9hJSG/wnWyttUUNZiUaTLrA9YHT357Pc+tGk0ZgS5nagS+K9ow2am4 HLw0RxQ8Os7ZvVxoZqozjd+VxFWeTsjFpXCVagLBTawAUiMIz0YOacVd7fqBIc8rYCX3sISGozf Z+mQVumnCol3zXKzc4aPHWZvpwH4zS0PGP8gOerYmnbRhJZXhWpXJczhaBJc3c0eLfO1fuhlVAQ Znd/qKIF6FOoFccVzoabqDWLP/CKqh4pAEJ4fYYUZ8FqfjlfyfvkcMmJB+qcu9MIOEzmgh0K7hF gi3AxpCyTaVyHuUVxK/0SCKePp0uBAXoA1Af/0FhU4eWC84vC7Odk7yCfVoi/MZOpzGQW4UXXMJ b1A16r8AeMpLPdWc5JQg1rdrZGA== X-Google-Smtp-Source: AGHT+IGxWioWzkteVPao5Dq0WvZrsx/AuHQU4Sefx/aMIOjHNSoSL3eTBRi0PhWf6Z0xPBAaK/6NW1RLTp6D+JMTs14= X-Received: by 2002:a05:7301:c14:b0:2a4:3593:6477 with SMTP id 5a478bee46e88-2a71930cb4fmr5389907eec.39.1763966242094; Sun, 23 Nov 2025 22:37:22 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <86ldjw86vi.fsf@ltc.des.dev> In-Reply-To: <86ldjw86vi.fsf@ltc.des.dev> From: Ankush Mondal Date: Mon, 24 Nov 2025 12:07:10 +0530 X-Gm-Features: AWmQ_bmGJ5p9yxzaoRVSPIM8fn3gMhwahVAUJGBw8Fo8uQZuWDruci814KLaFxc Message-ID: Subject: Re: How to get started with FreeBSD dev To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Cc: hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000004183e90644516549" X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dFGMr2sdtz3sRj --0000000000004183e90644516549 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, I am going for it !! How do you assign me this task? On Mon, Nov 24, 2025 at 8:38=E2=80=AFAM Dag-Erling Sm=C3=B8rgrav wrote: > Ankush Mondal writes: > > [...] Could you guide me on how to get started with FreeBSD > > development? > > Assuming you've already installed FreeBSD and figured out how to build > and install it from source, and you know C, here are a few recent bug > reports that should be approachable by a beginner: > > https://bugs.freebsd.org/290710 > https://bugs.freebsd.org/290711 > https://bugs.freebsd.org/291027 > https://bugs.freebsd.org/291141 > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org > --0000000000004183e90644516549 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, I am going for it !! How do you assign=C2=A0me thi= s task?

On Mon, Nov 24, 2025 at 8:38=E2=80=AFAM Dag-E= rling Sm=C3=B8rgrav <des@freebsd.org<= /a>> wrote:
A= nkush Mondal <ankushmondal1y2t@gmail.com> writes:
> [...] Could you guide me on how to get started with FreeBSD
> development?

Assuming you've already installed FreeBSD and figured out how to build<= br> and install it from source, and you know C, here are a few recent bug
reports that should be approachable by a beginner:

=C2=A0 https://bugs.freebsd.org/290710
=C2=A0 https://bugs.freebsd.org/290711
=C2=A0 https://bugs.freebsd.org/291027
=C2=A0 https://bugs.freebsd.org/291141

DES
--
Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org
--0000000000004183e90644516549-- From nobody Mon Nov 24 10:45:41 2025 X-Original-To: hackers@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 4dFMtH5FHHz6JTH7 for ; Mon, 24 Nov 2025 10:45:43 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dFMtH4bZ4z3FVL; Mon, 24 Nov 2025 10:45:43 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763981143; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kkPQHWC5uJyXCeIIPF4nXnEIEpX5/vM0nhXvuM6EfE8=; b=dft5HGfL5eFMr2zyU/gMEbvGDGg/YWp86hN+3prtreTFUE97VptgvUaar4PzFIyMjfCzWz y7l+BliW6TcE92agenpQYBp6ZV241E3Ap+OHCMEA5r6GpB+U/mr/lgu5s+fMAPm5cjhhp6 92WHe3rAVZq0xbIOnhla+zyxteIFuEX6ftFqrqIQyB58W0xwGoq8304c/ijRfA3EACCjOd c46ojJgjxTXkonyx+bjzfJN0AS5bXFCT4zLrLzAa7v/VyGrrqY313eEt+eSrMWkAvSP9RA zCkiJWh6LHUn8Uwb+pO0vCUS7NdNuS8MU7IrPFSEMvfW20/yO5f6KSMuBZIvrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763981143; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kkPQHWC5uJyXCeIIPF4nXnEIEpX5/vM0nhXvuM6EfE8=; b=UxgClFZkvDRdaQDbeUn+eYqpP074cnxfMudbs01hyPXlXHdGmndqAbcIIPQAWOpzHx1LsC ts/1AJ0a+U+HE7lsm+jCwITNMM6MwxR0Sw03w+71cY/x+I5ZXJFTh6yHZpNh3CNrBQX3jF pYn57eFTvI9w9Jtc1ZOVzV3J4gZWWfDQOM9Ig4PJza9tublzAX6LH604VuORuyycv99RnR eUBDOyhfLS37xrlEF9fbA5grvkzC4Iq4Hox2V8FWlCLy3E0SeAY3rh9YqA/Hs2dGtMhoxh zpkaMaLjZSORYpG7nVs0bV/uf4l8PvPc5yxrMB+fBKEnDE9C8e1+lq5WVfTGwg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763981143; a=rsa-sha256; cv=none; b=VXVQmabPjg2HpjhAHYlgIm1rHoXy8IgMClSwgXkEPOfB1hco2lDY3QvhUPPgn/NmOcj4Oe VxUCCstU8uGxoO9e2sIL9QtbJTfoNV1J1bzVY/XBNU3FV8FaaTzYj8XNMmUQJWe6XNwIxI OB/t2JiG+5sPOTQEuizB6Yy7v5L49XmEFz2WnQIREA6iiOrV6khYJDUN/wzUh3n+4NLbLY bZZc3k1evohPqmKW7j/DG2TgO+wnSKmgWhFU2iRluWwRoP28hNZFDebvrDQmAsr8Lgo6Yj 3J4uZIl7lF1X6QiXi4l1vfI4CRRhiQKmq8e+IOuu/XIox7aul9bt5AWN1mM3tQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (2a01cb0585090500922e16fffef1acef.ipv6.abo.wanadoo.fr [IPv6:2a01:cb05:8509:500:922e:16ff:fef1:acef]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dFMtH3Gr8znsJ; Mon, 24 Nov 2025 10:45:43 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id B37A18E1A3; Mon, 24 Nov 2025 11:45:41 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ankush Mondal Cc: hackers@freebsd.org Subject: Re: How to get started with FreeBSD dev In-Reply-To: (Ankush Mondal's message of "Mon, 24 Nov 2025 12:07:10 +0530") References: <86ldjw86vi.fsf@ltc.des.dev> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Mon, 24 Nov 2025 11:45:41 +0100 Message-ID: <86a50b90a2.fsf@ltc.des.dev> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ankush Mondal writes: > Thanks, I am going for it !! How do you assign=C2=A0me this task? I'm not assigning anything to anyone, just suggesting some issues that might be within your reach. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Mon Nov 24 12:37:34 2025 X-Original-To: hackers@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 4dFQMl0Xfwz6H7Sc for ; Mon, 24 Nov 2025 12:37:55 +0000 (UTC) (envelope-from ankushmondal1y2t@gmail.com) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 4dFQMk2NcLz3Rfl for ; Mon, 24 Nov 2025 12:37:54 +0000 (UTC) (envelope-from ankushmondal1y2t@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=X7zfi+M6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ankushmondal1y2t@gmail.com designates 2607:f8b0:4864:20::52a as permitted sender) smtp.mailfrom=ankushmondal1y2t@gmail.com Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-bc4b952cc9dso3887593a12.3 for ; Mon, 24 Nov 2025 04:37:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763987866; x=1764592666; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=++xaQJTxF9Od6fWpUifRYHF0da2mvzdoE6AdtKRDS7M=; b=X7zfi+M6S6u9jRc1OClBkWpmDDokJu0eX3UY9Fn254FKKGm+P/FD6xdF2GJy2H4JBE NH32Na/a3mxWiMF28/JE+1fMg9N7pbRA1hCASI+gHc/FNAYLf6rZqSJ3yp/QHfmIuG63 RT+mpw+vtkDrCFWwdHiZ5HhtzqrX4CAljB3THdkiZXy/CI0WwYx0ZCn8J0pGWpJzIr6z qVEeTqM9X92Wj39TIRORGZokMXrPKMTmNVH9ZLAuF6kBOnPw8QT/O8TzvcoxtRsHFmis bwsaKH/uSGYB8cO/TxCc4G+kiHu17O+VhzGyORka7VFggQUzuEJ744kDcWf3BiD3/mb4 /2+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763987866; x=1764592666; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=++xaQJTxF9Od6fWpUifRYHF0da2mvzdoE6AdtKRDS7M=; b=ww//mbWF3bx+369XJASCCSfkGzL3f65pf6kdZvzlIaMMMdeq0vcMb5Dpy367y7qkfI faLW3qTRm+zML0SjhNhnSbn+oujb0KeMCpZ+/0YhbwdIvPbcPXwpjo6xvp8dpr0jq0yW n7xz3A8ID9xRxOcnPiWfo7O+AUsJPY82lUvyf207MaXxetuBTb80vt3k6nCSHQa4eMsW A+lsd8YOtK58yZChM+D22KNTAbNUg1fe1kyC77QK5i2/9zd7mseyAizM0WLhgj1Ui8Z2 vyNkToS97E00RHM7OZ1HtSdVqJID8exhgLalzjtcKwy08dHKyi3UIcGFEFTwfYpXrc4i wSOA== X-Gm-Message-State: AOJu0YxtdWbR4BwJNUaNiR2FGwdweXClI1GoHPEivUbK98d3LmKEwzGJ Budp9/kNG3anhH6abjSWQy3gT4NplGi5LCwhwm6mlUsfCQmSDL/sv9vxSuuP9q0SzzIwmtVniJH QaDFhSS7usuv3l6cxjZ3IOhtbmaJkULUjLJSxtNANvg== X-Gm-Gg: ASbGnctmgFpxq2Ki4PCcj5XUTAn7kT4bxeaP9XYqTxnzRypWVCwWkkSgpjVIp2oJEJQ HhHjWeXkfEzYv0a4T+fQtOXc+J7y/tLOMXwJgONS0BTjIECDt7NyB3WxJcwiu0EQHNEhe//QFL8 dEUj6YupjrxXsjq98ksP0K/6N1myhBpNi7GP4sOsyCdrfVp7hepMtdHaTsPwxILJQz5y34JOde4 RWFvbHrcczyzJHjaq/636xjDDruUHqThIN3/QIrMx61k+IeoAppAHLJycGovZIYZ0DeiqFB81DP gttDkTRH76L0err3hKF2c8PxgBim/X3eXb48VHciADbqiCnFmUwn7Y0HfFejsl1hJ4zmw7e9mLx 2RQwwbN2LRJmJ56DlyiGXOdbrnQ== X-Google-Smtp-Source: AGHT+IHawAi814OjgJ/y1fOrLqX2CmrQ31mQ75GVq4bD+YExdQejxns90WvWq3Egf/4LTgm9iB8pOkyErW573Z5nozY= X-Received: by 2002:a05:7301:19ad:b0:2a4:4885:6cc0 with SMTP id 5a478bee46e88-2a71956ad37mr6439814eec.14.1763987866363; Mon, 24 Nov 2025 04:37:46 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 From: Ankush Mondal Date: Mon, 24 Nov 2025 18:07:34 +0530 X-Gm-Features: AWmQ_bm4-Yhca4kon4XZCwZ-hdnqY-cOmpy00Oqz70dBZ1B3IOV14GJoAaaG8Rg Message-ID: Subject: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) To: hackers@freebsd.org Content-Type: multipart/mixed; boundary="0000000000002a2e0f0644566e52" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_MEDIUM(-0.82)[-0.820]; NEURAL_HAM_SHORT(-0.58)[-0.575]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain,text/x-patch]; MIME_BASE64_TEXT(0.10)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52a:from] X-Rspamd-Queue-Id: 4dFQMk2NcLz3Rfl --0000000000002a2e0f0644566e52 Content-Type: multipart/alternative; boundary="0000000000002a2e0f0644566e50" --0000000000002a2e0f0644566e50 Content-Type: text/plain; charset="UTF-8" This patch fixes the inconsistency in df -k header formatting described in Bug 290710 . Before : root@bsd:~ # df -k Filesystem 1024-blocks Used Avail Capacity Mounted on zroot/ROOT/default 65618056 4716712 60901344 7% / After : root@bsd:~ # df -k Filesystem 1K-blocks Used Avail Capacity Mounted on zroot/ROOT/default 65618056 4716712 60901344 7% / --0000000000002a2e0f0644566e50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This patch fixes the inconsistency in=C2=A0df -k<= /code>=C2=A0header formatting described in=C2=A0Bug 290710= .

Before :=C2=A0
root@bsd:~ # df -kFilesystem =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1024-blocks =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Used =C2=A0 =C2=A0 Avail Capacity =C2=A0Mounted on
zroot/R= OOT/default =C2=A0 =C2=A065618056 =C2=A0 =C2=A0 4716712 =C2=A0 60901344 =C2= =A0 =C2=A0 7% =C2=A0 =C2=A0 =C2=A0/

After :
root@bsd:~ # df -k
Filesystem=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A01K-blocks =C2=A0 =C2=A0 =C2=A0 =C2=A0 Used =C2=A0 =C2=A0 Avail= Capacity =C2=A0Mounted on
zroot/ROOT/default =C2=A0 =C2=A065618056 =C2= =A0 =C2=A0 4716712 =C2=A0 60901344 =C2=A0 =C2=A0 7% =C2=A0 =C2=A0 =C2=A0/

--0000000000002a2e0f0644566e50-- --0000000000002a2e0f0644566e52 Content-Type: text/x-patch; charset="US-ASCII"; name="fix-k-flag-blocksize.patch" Content-Disposition: attachment; filename="fix-k-flag-blocksize.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mid4tcdm0 ZGlmZiAtLWdpdCBhL2Jpbi9kZi9kZi5jIGIvYmluL2RmL2RmLmMKaW5kZXggZGI1YjhiMThiZWFl Li5lOWM3N2VkOTU0M2QgMTAwNjQ0Ci0tLSBhL2Jpbi9kZi9kZi5jCisrKyBiL2Jpbi9kZi9kZi5j CkBAIC0xNTQsNyArMTU0LDcgQEAgbWFpbihpbnQgYXJnYywgY2hhciAqYXJndltdKQogCQkJYnJl YWs7CiAJCWNhc2UgJ2snOgogCQkJa2ZsYWcrKzsKLQkJCXNldGVudigiQkxPQ0tTSVpFIiwgIjEw MjQiLCAxKTsKKwkJCXNldGVudigiQkxPQ0tTSVpFIiwgIjFrIiwgMSk7CiAJCQloZmxhZyA9IDA7 CiAJCQlicmVhazsKIAkJY2FzZSAnbCc6Cg== --0000000000002a2e0f0644566e52-- From nobody Mon Nov 24 16:03:06 2025 X-Original-To: hackers@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 4dFVwm3NXnz6HR2d for ; Mon, 24 Nov 2025 16:03:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 4dFVwm0m2Jz3tsj for ; Mon, 24 Nov 2025 16:03:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-3436d6ca17bso4500012a91.3 for ; Mon, 24 Nov 2025 08:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1764000197; x=1764604997; 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=UtjHOIB689CgBftwVjkBbRQQIpXHUTP7HTNgVHrkMLs=; b=wNv1Hh0tvqEZKmGcjLXOatRJpII62COs4bDnlESd3Capn+TYseebi7U1LfDQHwrQur vpHFsu+r/VKGpkfKHmLgwjjFfRxEA/7sa9TOkYjx597JP/Dj6Cl8Fp4LUWHQ5TPutM7w NresgdtlmGnpM9JRvXnj52FkC3iT92w1BkzB6BAKWk83308+5+GNcss5CwDoLQJetEHJ K7RS1UZnBQSmu3mbZ3KM2yqFNQx+kmzTbqdVoDF4fe31DCUFV45qeS6Y+EsrfBc+6eMk bsJIeU2q4KumVPsVYHabizao92ayG4FFX+GQddBHI2Rr0QmG5BfHUpy8xgFwpWvtHm1D 5H3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764000197; x=1764604997; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UtjHOIB689CgBftwVjkBbRQQIpXHUTP7HTNgVHrkMLs=; b=Q2o4y2ra2xAf0bDARBy1RiC8T+0JUHxsklaBVdj+6GZbLaDvxsotDzpXVgIgco9xEF u1IoUKRrTFlKsawS8UIy7YxgHeWfEOE/FjVO1VcSY1+Z0CF3KcIHko40V6f0+J2zrGsN /0ycrKPTGmlEkD5JEVVcU5rRK7VFRWMXBTBMONhJWZJJbdDikSr/qmIJcu1wobigc5NK BlsTqGG4do8M5WYPXt2lLBnTjWSO4JYsfJY2wacMXC4pTeJIXvz6iT3AQNOBTaKfZ7Wz /TWWM1rrlWaR7YMAsHpB1Ckj/H6PZlbPZi1RprulQkIOyyWrqf8CP9inypFIDREKGt2Q d7iw== X-Gm-Message-State: AOJu0Yx2OILNoL6ONFmqnpg1esqgXfFk/vvOZ2dkMM9SZFvJOmr9szE5 iUTA7vZ1a0qdPTluDws+eh1NIDN5Riv6vV115DbRWM4OG0GTwLLGu1RWCEozCP34EYhDMyzzYaM WbctJrJzR9P18oXWNDkJ1rEECJATGS+ufaW8rDAhexA== X-Gm-Gg: ASbGncuIuRc+tKHT8CQyeSVcmvfvpea/DS6knPtUdyBjZADaT1VEPXG9BgXB9ARKaT6 41FwH432pOhUr3/dvUPjb5PxiGda2mB1Tmh+It3WXVzo18qCewONMSbS+lBh85nR6DDtDrvEnQJ JyWfJD1/xSYhZE3kWOWjEdCwusw8Wav1+1SpshcKnxx58RZaURlHEZl8vt0QvqCc84rxk+wBbTC IpyxqUWU5ISQdj4VLErU/srnvkyjtOu3sCOparolChokHkoyqqVU953l1hpedIt1G6+6Mk= X-Google-Smtp-Source: AGHT+IEm/dG4AusBTV0/kye4fgwoOHE3T1Ed7cDQQlIyPOAnYB4dhzazUs1UbT3gBPF/9ZY7TUID6gosQY89FM7AT1w= X-Received: by 2002:a17:90b:224e:b0:33e:2d0f:479b with SMTP id 98e67ed59e1d1-34733e4683cmr12525299a91.6.1764000197200; Mon, 24 Nov 2025 08:03:17 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 24 Nov 2025 09:03:06 -0700 X-Gm-Features: AWmQ_bl0uQ_htB3uAnvUEdgsgvrv3hnQj7_mXaH8Axe6xqrWud0M0S961qkSVDk Message-ID: Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) To: Ankush Mondal Cc: hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000235ca60644594dc7" X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dFVwm0m2Jz3tsj --000000000000235ca60644594dc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think this is the wrong direction of the fix. POSIX-2023 states: STDOUT When both the *-k* and *-P* options are specified, the following header line will be written (in the POSIX locale): "Filesystem 1024-blocks Used Available Capacity Mounted on\n" and so this goes from the recommended form to a non-conformant form. While the implementation is free to use 1k instead of 1024 when -P is not specified, I think this change will break that. Also, we generally don't do code reviews in hackers@. Your best bet is likely a github pull request. I'll keep my eyes open there. Warner On Mon, Nov 24, 2025 at 5:38=E2=80=AFAM Ankush Mondal wrote: > This patch fixes the inconsistency in df -k header formatting described > in Bug 290710 > . > > Before : > root@bsd:~ # df -k > Filesystem 1024-blocks Used Avail Capacity Mounted > on > zroot/ROOT/default 65618056 4716712 60901344 7% / > > After : > root@bsd:~ # df -k > Filesystem 1K-blocks Used Avail Capacity Mounted o= n > zroot/ROOT/default 65618056 4716712 60901344 7% / > --000000000000235ca60644594dc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this is the wrong direction of the fix.

POSIX-2023 states:

STDOUT

When both the=C2=A0-k=C2=A0an= d=C2=A0-P=C2=A0options are specified, the following header line will= be written (in the POSIX locale):

"Filesystem 1024-blocks Used Available Capacity Mounted on\n"
and so this goes from the recommended form to a n= on-conformant form. While the implementation is free to use 1k instead of 1= 024 when -P is not specified, I think this change=C2=A0will break that.

Also, we generally don't do code reviews in hacke= rs@. Your best bet is likely a github pull request. I'll keep my eyes o= pen there.

Warner

On Mo= n, Nov 24, 2025 at 5:38=E2=80=AFAM Ankush Mondal <ankushmondal1y2t@gmail.com> wrote:
=

This = patch fixes the inconsistency in=C2=A0df -k=C2=A0header format= ting described in=C2=A0Bug 290710.

Before :=C2= =A0
root@bsd:~ # df -k
Filesystem =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 1024-blocks =C2=A0 =C2=A0 =C2=A0 =C2=A0 Used =C2= =A0 =C2=A0 Avail Capacity =C2=A0Mounted on
zroot/ROOT/default =C2=A0 =C2= =A065618056 =C2=A0 =C2=A0 4716712 =C2=A0 60901344 =C2=A0 =C2=A0 7% =C2=A0 = =C2=A0 =C2=A0/

After :
root@bs= d:~ # df -k
Filesystem=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01K-blocks= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Used =C2=A0 =C2=A0 Avail Capacity =C2=A0Mounte= d on
zroot/ROOT/default =C2=A0 =C2=A065618056 =C2=A0 =C2=A0 4716712 =C2= =A0 60901344 =C2=A0 =C2=A0 7% =C2=A0 =C2=A0 =C2=A0/

--000000000000235ca60644594dc7-- From nobody Mon Nov 24 16:38:21 2025 X-Original-To: freebsd-hackers@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 4dFWjX6gKcz6HTMD for ; Mon, 24 Nov 2025 16:38:40 +0000 (UTC) (envelope-from friedrichdoku2030@u.northwestern.edu) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 4dFWjW5pxkz40RW for ; Mon, 24 Nov 2025 16:38:39 +0000 (UTC) (envelope-from friedrichdoku2030@u.northwestern.edu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=u-northwestern-edu.20230601.gappssmtp.com header.s=20230601 header.b=nX2p4oPX; dmarc=pass (policy=none) header.from=northwestern.edu; spf=pass (mx1.freebsd.org: domain of friedrichdoku2030@u.northwestern.edu designates 2607:f8b0:4864:20::332 as permitted sender) smtp.mailfrom=friedrichdoku2030@u.northwestern.edu Received: by mail-ot1-x332.google.com with SMTP id 46e09a7af769-7c75e5b154cso397033a34.2 for ; Mon, 24 Nov 2025 08:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=u-northwestern-edu.20230601.gappssmtp.com; s=20230601; t=1764002312; x=1764607112; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=hxs0L9lCrIFgsbAIYkisp/MSVSw9+c/GRiZxcTvnqMk=; b=nX2p4oPX/m9YuGcqrx1Iz4wFa1uZtfKYkGNDo4TaRF86HM9QWLIO5CncEJcdMCYWV7 IV5sdVSVhI6/kApIOteITLBOmHRVWrdYb7vv1dcPa+umhdwzMI6lI76dtLspxwggT+K9 /R9gQjs2rgD7EKftqgSaNZBejHIO/saxFu+HwI7E2GXE1cy2UeQflchBgACjnsa8l1+M Z4gGJPGZBb/swxdNxqsc096urs1SX7zbPWKj+xi0P4C294F7k+1zyu5cIPZp3itZhL0j nDvqMeO5nctordu0RvKG+RMffNop+DLYGMH4yDtE64eVy88R44Dypj7NK3FZfnAg+MpW g4oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764002312; x=1764607112; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hxs0L9lCrIFgsbAIYkisp/MSVSw9+c/GRiZxcTvnqMk=; b=msZKdUaEAVRSqJuc7JaQVL9BiqxWFNtaWDESLbeYzauO02l1K6LWkLPuBV798G4zoO z579FwvoR3FS8vWzKkqmlzJLABmvQhpn/N40Fa8uRe8TyoWpCiAT0xuxRpy4Ls/kZCBs aBz1fX1h5KCUzxCFfuDyER1/j/SzRbr2I0Wo/Eg9Romb1rZq+/Kga5ZxbxR1kPJEsMw5 j+0AoqPtIQmj6fiqNlsW5nib+SoW8oXWsuCf1pOt2ypmymkVUTpKhzxFlK2l/Of/qFQQ vvpmcmlsOV0cg3/4mIfxGrj0VB2iklwuvwVURaSKvPrOr5KcGslYSLmTkYVVQvXqE643 +g1g== X-Gm-Message-State: AOJu0YwRWxzH3rhP60D8F0xwpTnvnI141wPc1tVVW0GkcgFEtmwR3US+ IGQeal9swmNbFSq/9+EcsjjMX7pO/CXuyUHgzl/HBzmPa5CcqO4eS2gXs6PPMMKtVQAd+7ZrDQT dpjzLSOkwwQc/WYAVaA4T0/EmoV62RhsxNlcC2WQNSYHkY/1VJRGLSFwVWg== X-Gm-Gg: ASbGncsCMreZ8KT64V1Zgbxj2Z1xz4xFOuqLW6XubFJO7qi3D5Zd6KuMdV0vyHR/1bI YLKOvx6XfZP9HQEM+qsQ10DnPOUbIz7UHGUh6IabIhkqxPt/fUg7GeIkHIWhwGwcq7TofDkToJO E0aZdoh6VZhzwioM28VFRTTpmHqR7e+pKEKaqnZJtgkmvPbET4H3NAzDDKr/b+xPo2SzhW9cwAx RZIU2COzVwNevhdAvrw5tb+R95cHZkaXiaZArt0MqmaGVSJqokGmnhKA3p6wvmBEBU9ymopPsQK 6ZGp+tPZhTWvMbNIXVb/562sLS5eRvVX4as95NT3qnCHO+vPjt4XbSHaIsDf35WhPmM= X-Google-Smtp-Source: AGHT+IGkiIqUf2WGdGd26HTMQH4Mbr8JQQIt4ul6EjpScpmk3Lp6xuqFHdSJ+GLKLcmRkyxnrYJZ/nmD/EZIdR8cF0Q= X-Received: by 2002:a05:6830:4386:b0:7c7:6309:d935 with SMTP id 46e09a7af769-7c79d580b98mr3098420a34.2.1764002312404; Mon, 24 Nov 2025 08:38:32 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 From: Friedrich Doku Date: Mon, 24 Nov 2025 10:38:21 -0600 X-Gm-Features: AWmQ_bmOCkFvJimRLi2UcTwTnH6Fakils193uB3req_c3xMpCHKo0-aWUnyKXco Message-ID: Subject: mmap of PCI BAR0 returns 0s in userspace To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000036d057064459cbf9" X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[northwestern.edu,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[u-northwestern-edu.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[u-northwestern-edu.20230601.gappssmtp.com:+]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::332:from] X-Rspamd-Queue-Id: 4dFWjW5pxkz40RW --00000000000036d057064459cbf9 Content-Type: text/plain; charset="UTF-8" Hello, I'm working on a custom e1000 driver, and I want to map the MMIO addresses into userspace, so I wrote an e1000 driver using .d_mmap to do this, but for some reason I can only access the register values in the kernel and not in user space. I'm just getting all 0s in userspace. When I mmap this character device in userspace, the mapping succeeds, but reading from the pointer returns all zeros (0x00000000). I'm on aarch64. I'm even mapping the memory as VM_MEMATTR_UNCACHEABLE. Any suggestions? driver code user space program code *DUMPING IN KERNEL* e1000_map module loaded. Device: /dev/e1000_map Mapping BAR0 Base: 0x70100000, Size: 0x20000 DEBUG: Kernel read of BAR0[0] (CTRL): 0x18100209 DEBUG: Kernel read of MAC: 98:b7:85:01:93:b5 *IN USER SPACE* === Intel E1000 Register Dump (Userspace) === e1000_map_mmap: offset=0x0, paddr=0x70100000 Device Control and Status: CTRL (0x00000): 0x00000000 STATUS (0x00008): 0x00000000 (Link: DOWN, Speed: 10Mbps) e1000_map_mmap: offset=0x5000, paddr=0x70105000 MAC Address: RAL (0x05400): 0x00000000 RAH (0x05404): 0x00000000 MAC: 00:00:00:00:00:00 === End of Register Dump === Best, Friedrich --00000000000036d057064459cbf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I'm working o= n a custom e1000 driver, and I want to map the MMIO addresses into userspac= e, so I wrote an e1000 driver using .d_mmap to do this, but for some reason= I can only access the register values in the kernel and not in user space.= I'm just getting all 0s in userspace.=C2=A0

When I mmap this ch= aracter device in userspace, the mapping succeeds, but reading from the poi= nter returns all zeros (0x00000000). I'm on aarch64. I'm even mappi= ng the memory as=C2=A0VM_MEMATTR_UNCACHEABLE.

An= y=C2=A0suggestions?


DUMPING IN KERNEL
e10= 00_map module loaded. Device: /dev/e1000_map
Mapping BAR0 Base: 0x701000= 00, Size: 0x20000
DEBUG: Kernel read of BAR0[0] (CTRL): 0x18100209
DE= BUG: Kernel read of MAC: 98:b7:85:01:93:b5

IN USER SPACE
= =3D=3D=3D Intel E1000 Register Dump (Userspace) =3D=3D=3D
e1000_map_mmap= : offset=3D0x0, paddr=3D0x70100000
Device Control and Status:
=C2=A0 = CTRL =C2=A0 =C2=A0 (0x00000): 0x00000000
=C2=A0 STATUS =C2=A0 (0x00008):= 0x00000000 (Link: DOWN, Speed: 10Mbps)
e1000_map_mmap: offset=3D0x5000,= paddr=3D0x70105000

MAC Address:
=C2=A0 RAL =C2=A0 =C2=A0 =C2=A0(= 0x05400): 0x00000000
=C2=A0 RAH =C2=A0 =C2=A0 =C2=A0(0x05404): 0x0000000= 0
=C2=A0 MAC: 00:00:00:00:00:00
=3D=3D=3D End of Register Dump =3D=3D= =3D

Best,
Friedrich
--00000000000036d057064459cbf9-- From nobody Mon Nov 24 22:30:39 2025 X-Original-To: hackers@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 4dFgWn1S2Gz6Hx4b for ; Mon, 24 Nov 2025 22:30:45 +0000 (UTC) (envelope-from linimon@portsmon.org) Received: from MTA-14-3.privateemail.com (mta-14-3.privateemail.com [198.54.127.110]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dFgWm5hSRz3nfg for ; Mon, 24 Nov 2025 22:30:44 +0000 (UTC) (envelope-from linimon@portsmon.org) Authentication-Results: mx1.freebsd.org; none Received: from mta-14.privateemail.com (localhost [127.0.0.1]) by mta-14.privateemail.com (Postfix) with ESMTP id 4dFgWk0CHLz3hhVT; Mon, 24 Nov 2025 17:30:42 -0500 (EST) Received: from APP-04 (unknown [10.50.14.154]) by mta-14.privateemail.com (Postfix) with ESMTPA; Mon, 24 Nov 2025 17:30:39 -0500 (EST) Date: Mon, 24 Nov 2025 16:30:39 -0600 (CST) From: Mark Linimon To: Warner Losh , Ankush Mondal Cc: hackers@freebsd.org Message-ID: <1789299192.176069.1764023439861@privateemail.com> In-Reply-To: References: Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.6-Rev84 X-Originating-Client: open-xchange-appsuite X-Virus-Scanned: ClamAV using ClamSMTP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22612, ipnet:198.54.127.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dFgWm5hSRz3nfg > On 11/24/2025 10:03 AM CST Warner Losh wrote: > Also, we generally don't do code reviews in hackers@. Your best bet is likely a github pull request. I'll keep my eyes open there. Then that's even more bad advice in the various Articles/wiki. I'll put it on the ever-increasing list ... mcl From nobody Mon Nov 24 23:26:05 2025 X-Original-To: hackers@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 4dFhlp3vHBz6J1x6 for ; Mon, 24 Nov 2025 23:26:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dFhln6pKMz3vQk for ; Mon, 24 Nov 2025 23:26:13 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 5AONQ5j0013270; Tue, 25 Nov 2025 08:26:07 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1764026767; bh=lJD2HnWlAZo0UDG/K9ObuHlXHsGMcblXIi0jrAfj9t4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=eJKWlj3sKFl200Y/tGqKzE3RjTEyeBZg7xbjZk/xwCNkWuJA++Mi4cL7Uuxq6kOah GysmgWZvDIvNSFGTne3mTAJbPs0WE0jCzUJ9dtdMaeMsjlC6S/PLjy3c2Mno1EsuWa js22uszKO4GreLB08ZeBdnjW3mwvcnXSpwFvvvhw= Date: Tue, 25 Nov 2025 08:26:05 +0900 From: Tomoaki AOKI To: Mark Linimon Cc: Warner Losh , Ankush Mondal , hackers@freebsd.org Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) Message-Id: <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> In-Reply-To: <1789299192.176069.1764023439861@privateemail.com> References: <1789299192.176069.1764023439861@privateemail.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dFhln6pKMz3vQk On Mon, 24 Nov 2025 16:30:39 -0600 (CST) Mark Linimon wrote: > > On 11/24/2025 10:03 AM CST Warner Losh wrote: > > Also, we generally don't do code reviews in hackers@. Your best bet is likely a github pull request. I'll keep my eyes open there. > > Then that's even more bad advice in the various Articles/wiki. > > I'll put it on the ever-increasing list ... > > mcl The best way for code review with FreeBSD is Phablicator for me. The accounts are managed by FreeBSD project (or FreeBSD foundation), unlike github. And works fine for me (with some difficulty, though, on opening review with adding files, but it can be overcome). -- Tomoaki AOKI From nobody Tue Nov 25 03:17:26 2025 X-Original-To: hackers@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 4dFntc4f3Mz6HM8p for ; Tue, 25 Nov 2025 03:17:28 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dFntc46Xyz3T05; Tue, 25 Nov 2025 03:17:28 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764040648; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=O9nft+l7NIp8Wv7FdgYVt1kEX6cdE8P7HqNj+egCUXU=; b=fT9uMALU6Jm33pKewyKk3lQ+2kxpJPbESh5XP7UslQ04xh3NIrUIivv/5GuFgZLiSWk4JX lU6gpCbk/Yo19la01hzYn4NS8zM1JjEfFHhWN9S7vV4fz9DYC/wW8Dlx1dyPq2r1KEnVxT SSGGDUopVxf5u61pG1dmhspQY3HzPJdHw11qFBzcOKfsrHE8Pr+boz+KTAOoDACAqCUXKG f1iB6xAlToJWSCQsQehL48u5ZzRbBtVu6uKaZSy6fj+EkBBkSgbvYrxEFb72RwSvaI4Pjw UrbhhjqAE4STDI3VgNCaMBGrp1wTUlBTBu6CDbDIxtBnbKiVZALelJCnK8Hd1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764040648; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=O9nft+l7NIp8Wv7FdgYVt1kEX6cdE8P7HqNj+egCUXU=; b=PrVWLHmqiWgBuLhHdaCivFqoS1XGZg+R61tuhqLJg3cUtiMNsaMBPrGTLiEU3un3uYVbfP Dk9aNZ4gUHJUxqVgNa605mcfSus4TGnyLWMbkOwpyPVj8pC/Eh1X5V3ZR2OPeQD+EJtiln xBc58L0FWkBrfj3UOIRMML4vaFjnxcVGGInJH0sVbqaz16pGIrcrCMyoVz0uimZJvV1+9t cZG8a7A4soWPWOQJJf6+FCpECkSL8iPVZ4Ncau45u1gyn4dLtFJSB3r1uFCVBFDiWgCI6A 7mDbJYfohFFPUkrE73dL/ORKs2sEgb+WFS3hYPLkOaj6DpCQqAG16V9htQPlIg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764040648; a=rsa-sha256; cv=none; b=j0MbBiyx4ByEHa3FQMvyqH6r/57GQxCVQcSY86Zb8zysne0Nxezfhwz1clfoLwlLtFIpg4 ZLUcj3v5X32am25pote0Dl9ZfVQ9h/Zq+nImpJM+rMD0jdtyJ4Hw0/EDz9ps2zOasTXhCm UDa3VGc/ftrhFK+ydkfZY2DvWueXMlSsMnBG36rWd/HyQyw81iZyUKxxtryeWu+MW/VCdM /egaXBQOHA56i18HBpUT3jw4pRLKYxIm99OaM/8H3uLt36v9Wma2Q0xaKSA/lLJmi4phEF 2l3hq3Q4CbbRG9LjaXDHdGUkbpeTVbkMHJWvtWwz/7hv9aONE3ExV2leLxfNfQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (2a01cb0585090500922e16fffef1acef.ipv6.abo.wanadoo.fr [IPv6:2a01:cb05:8509:500:922e:16ff:fef1:acef]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dFntc2b7Dz1863; Tue, 25 Nov 2025 03:17:28 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id B0FDC8E01E; Tue, 25 Nov 2025 04:17:26 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Tomoaki AOKI Cc: Mark Linimon , Warner Losh , Ankush Mondal , hackers@freebsd.org Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) In-Reply-To: <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> (Tomoaki AOKI's message of "Tue, 25 Nov 2025 08:26:05 +0900") References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 25 Nov 2025 04:17:26 +0100 Message-ID: <86h5ui7qd5.fsf@ltc.des.dev> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tomoaki AOKI writes: > The best way for code review with FreeBSD is Phablicator for me. > The accounts are managed by FreeBSD project (or FreeBSD foundation), > unlike github. The accounts are managed by the person you're replying to. > And works fine for me (with some difficulty, though, > on opening review with adding files, but it can be overcome). There is no difficulty if you use git-arc (from the freebsd-git-devtools port) like the committer's guide says you should. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Tue Nov 25 12:46:58 2025 X-Original-To: hackers@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 4dG2Ws5jPLz6J5vf for ; Tue, 25 Nov 2025 12:47:05 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dG2Ws1K6wz4Pqv; Tue, 25 Nov 2025 12:47:05 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 5APCkwu5026572; Tue, 25 Nov 2025 21:46:59 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1764074819; bh=EZacK/M8q2+SLWpd6putGGHsP3VxsrcGDVtLbra399s=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Uq1x1BpBtPvDpqhJDXjb1poCWdSTzPtgGc/nluB6bkAkLCxM7shbcVtfbOKVVrylZ Xp3CJPsOyQNQLU/AE6Xp/Ayw13USWwPD7LNE6QtAjJzHK+8v89W077woTE5/W5yprw KXGsu3d1HW5tjT8EPLcEgYxPxCtXIq84ZyHygnTc= Date: Tue, 25 Nov 2025 21:46:58 +0900 From: Tomoaki AOKI To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= Cc: Mark Linimon , Warner Losh , Ankush Mondal , hackers@freebsd.org Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) Message-Id: <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> In-Reply-To: <86h5ui7qd5.fsf@ltc.des.dev> References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> <86h5ui7qd5.fsf@ltc.des.dev> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dG2Ws1K6wz4Pqv On Tue, 25 Nov 2025 04:17:26 +0100 Dag-Erling Smørgrav wrote: > Tomoaki AOKI writes: > > The best way for code review with FreeBSD is Phablicator for me. > > The accounts are managed by FreeBSD project (or FreeBSD foundation), > > unlike github. > > The accounts are managed by the person you're replying to. Ah, thanks for maintaining the services you all! > > And works fine for me (with some difficulty, though, > > on opening review with adding files, but it can be overcome). > > There is no difficulty if you use git-arc (from the freebsd-git-devtools > port) like the committer's guide says you should. I cannot use devel/arcanist, which is called from git-arc.sh, as conflicting archivers/arc is pulled in by security/clamav. So my only choice is using web UI. And I'm not committing my local changes but stashing, as I'm not a committer and committing into local branch is not mandatory for me. I don't want n* number (in case src) to become different with official repo by missingly committing into officially existing branch instead of purely local one. git diff (with -U999999 for Phabricator) does good job unless any new files are added, but if anything are added, I need to 1. generate diff by git diff and manually add diffs for added files 2. reverse with the patch by 1. (Of course, dry-run first) 3. `git stash --include-untracked` to make unrelated diffs backed out 4. apply the patch of 1. 5. build (/ package for ports case) to be sure 6. `git stash --include-untracked` again to move the changes into stash 7. `git stash show -p --include-untracked -U999999 > path_to_patch` to obtain sanely applicable diff for Phabricator 8.`git stash pop` and reverse the patch of 6. to be sure. 9. `git stash pop` again to restore previous state without the patfh 10. apply the patch of 6. to restore actual previous state. Diff generated with above procedure are always sanely accepted by Phabricator web UI in my experience. (Hand crafted patch are often rejected.) Regards. > DES > -- > Dag-Erling Smørgrav - des@FreeBSD.org -- Tomoaki AOKI From nobody Wed Nov 26 02:05:24 2025 X-Original-To: freebsd-hackers@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 4dGNF83nM2z6JBLR for ; Wed, 26 Nov 2025 02:05:32 +0000 (UTC) (envelope-from freebsd-hackers-freebsd-org952@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dGNF80Tf3z469p for ; Wed, 26 Nov 2025 02:05:32 +0000 (UTC) (envelope-from freebsd-hackers-freebsd-org952@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=bmjVR91L; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-hackers-freebsd-org952@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-hackers-freebsd-org952@ketas.si.pri.ee X-Original-To: freebsd-hackers@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1764122724; bh=fE9OvhvswflZzvtwwa2R/Pmcx1vijZ7qXeOnDPuhMrs=; h=Date:From:To:Subject:In-Reply-To:References; b=bmjVR91LBlJt1j5yRm0yMv55Me2QGfe/sOG2ctkTAT/6bHNHgFfcAdS/RzMUTZ5KZ wQw6I7gt12CE40BlbFhd7L3IZQfUZ+sV7e1dnAIgfNWOGTWM1bUJJvPxcQ3Wx29CdA z+xsKVZ0xKn5IRx8XZqQxJHdOy4e646rg26zbvZCKyiiIXmZaPsvLIJlhP39+n8wZP ebuq9Q+5o+58w5FJLPOIOneAdTrTUr12LbrY0X5AbEHP7P0+RIvEt1A7hA0mLx1/2Q ENHbJcRWUuLfNamXol/OFVKDugxajiCWL6tCyycMw0cOXlo11m8CciR6bRLBkLr3yi Ts2qSJcqSMm5B1tARnRAT0HoeTSzStIrHMhaiixb6uVk/fHhhu1T0x6nOWI05BGYyq kXttFIb8SlwjpYGRnl059Bej5ckA/1GhuX93JTZKD5HBzEbM6hFMxILina7mwa3t+u 52/QDdmck/uAGJGsX7KXZ2xNp6cCWD1lR4DqgV7QrE901d4Rrf46v63I/kxDL1ZWKr L6yW2nqVWw2Lj8c6y+D0W9jCYeii3xyucd1H1rMwJf1RVbaM+VW3fR6q7+UhmoLm8c +dXGWf+EfmFD6Nvx2b1RipGKZIbap5Z9ZVYj1zuDTRxvB36hYis7Eg3xMtlLO29Jvu BvjvBg0Foi33FlD4oIVBPHpU= Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id A99A35B329E for ; Wed, 26 Nov 2025 04:05:24 +0200 (EET) Date: Wed, 26 Nov 2025 04:05:24 +0200 From: Sulev-Madis Silber To: freebsd-hackers@freebsd.org Subject: =?US-ASCII?Q?Re=3A_=5BPATCH=5D_df=3A_correct_BLOCKSIZE_han?= =?US-ASCII?Q?dling_for_-k_to_use_1K-blocks_=28290710=29?= User-Agent: K-9 Mail for Android In-Reply-To: <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> <86h5ui7qd5.fsf@ltc.des.dev> <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> Message-ID: <774F9B09-B506-4F8E-B293-CE705F64B77A@ketas.si.pri.ee> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: + X-Spamd-Result: default: False [1.12 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJ_EXCESS_QP(1.20)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.988]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; NEURAL_HAM_LONG(-0.29)[-0.290]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56:c]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4dGNF80Tf3z469p the diff procedures described here are totally insane i don't commit local or stash at all=2E i just modify local wd and keep di= ffs elsewhere recently i ran, eg git diff -U1000000 rc=2Econf | arc diff --raw in src tree unfortunately there is no file adder function?! having to do diff -rNu /var/empty/ sysutils/u-boot-orangepi-zero-2w/ in /usr/ports is absolute bollocks=2E it's even wrong! what would be sane way for both? if i don't have commit access and i don't want to touch "foreign" gits loc= ally right now i like only do git status --ignored git diff git log --name-status git clean -fdx note that other vcs'es have even worse ui i wish there's sane way to just get diff of untracked files so one can eit= her save them in nice format or submit patches that way like, git diff --include-untracked that would be it=2E just one command=2E make your local changes, save them= and send patch in instead you have to battle with local changes in remote repo=2E and now re= po is all messed up and you have to restore a state=2E i don't know how oth= ers work=2E what if i don't commit directly from repo? then it all falls ap= art i also see others battling and battling and battling with git=2E and again= , git has best ui of all vcs=2E others are much worse=2E i don't know which= brain shape one needs to have to like any of this but in case of me, it just pisses me off git pisses me off in my local repos too=2E like, if i add file, i no longe= r can diff it before i commit=2E i could git commit -v to see it tho i have absolutely no idea why any of this is good=2E someone designed it= =2E someone uses it=2E WHO likes it? the amount of time needed to battle with dev tools should be instead used = just to dev stuff=2E since i dev so little, i feel like i spend most of my = time fucking with git From nobody Wed Nov 26 02:42:46 2025 X-Original-To: freebsd-hackers@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 4dGP496qbqz6JDZq for ; Wed, 26 Nov 2025 02:42:49 +0000 (UTC) (envelope-from linimon@portsmon.org) Received: from MTA-07-4.privateemail.com (mta-07-4.privateemail.com [198.54.127.116]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dGP4923hcz3Brt for ; Wed, 26 Nov 2025 02:42:49 +0000 (UTC) (envelope-from linimon@portsmon.org) Authentication-Results: mx1.freebsd.org; none Received: from mta-07.privateemail.com (localhost [127.0.0.1]) by mta-07.privateemail.com (Postfix) with ESMTP id 4dGP472My3z3hhTW; Tue, 25 Nov 2025 21:42:47 -0500 (EST) Received: from APP-04 (unknown [10.50.14.154]) by mta-07.privateemail.com (Postfix) with ESMTPA; Tue, 25 Nov 2025 21:42:46 -0500 (EST) Date: Tue, 25 Nov 2025 20:42:46 -0600 (CST) From: Mark Linimon To: Sulev-Madis Silber , freebsd-hackers@freebsd.org Message-ID: <1497323956.336174.1764124966236@privateemail.com> In-Reply-To: <774F9B09-B506-4F8E-B293-CE705F64B77A@ketas.si.pri.ee> References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> <86h5ui7qd5.fsf@ltc.des.dev> <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> <774F9B09-B506-4F8E-B293-CE705F64B77A@ketas.si.pri.ee> Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.6-Rev84 X-Originating-Client: open-xchange-appsuite X-Virus-Scanned: ClamAV using ClamSMTP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22612, ipnet:198.54.127.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dGP4923hcz3Brt > On 11/25/2025 8:05 PM CST Sulev-Madis Silber wrote: > > the amount of time needed to battle with dev tools should be instead used just to dev stuff. I understand your frustration. But while this is true, there are ways to use git that do not actually require this level of effort. I am _certainly_ not a git expert and so I struggle with it, so I am not the right person to give you advice, but IIUC you are having more difficulty than most of the other contributors have. OTH, there is no bad intent here. Please take these into account. mcl From nobody Wed Nov 26 02:59:57 2025 X-Original-To: freebsd-hackers@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 4dGPSG5vpbz6JFlr for ; Wed, 26 Nov 2025 03:00:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 4dGPSG3xS7z3DyM for ; Wed, 26 Nov 2025 03:00:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-29555b384acso77867025ad.1 for ; Tue, 25 Nov 2025 19:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1764126008; x=1764730808; 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=PN0Zc7mLWpG6+SVLplpsc6Ho2C/k3Eifd5ZAcyZKZkc=; b=PfJL9iJBCRcEY50GG/Xmnrx6f7zxKF8FzCsBZd2YNxnPxAua/XuLWiTGKCPUOq1Yy8 GKmKzp8NI9EJWyxzS4wbaAH2PPmXTEKm8xbJLS/TgJVlLFFnWFBTV71bAG5IcoZMiyRo BNMEuXt5Kl3aNtJIhq03sbpHiLZEblpJ/ZsByqLguTKIj9oGtpnYrQgU+cCe0hMurMe/ jsfOzdMuaBRnBkMac58VC+n5cuoVUoT0U4OmGJmaed6uPrLg3gSoNcV5sxP8JOCY+I0Q djOrdteUzQ8W/C9+thqXiHQqT4a9sukQmz0NiduhB98LsuZ1S896Dyb/mSjmsHgGR45D Rrfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764126008; x=1764730808; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PN0Zc7mLWpG6+SVLplpsc6Ho2C/k3Eifd5ZAcyZKZkc=; b=FEVZzrzgXPV96GFEeyJuk9+AT51P5jh6AlnF5aQBoog7m54imhIUzaddQyMft7sQqS n38wFvkmqJMmzUJ96/Wy4ufCWm7D5h9i6xKWbbBOOVWaIK3clPxK+hhZyL9NeECNcCXi 9u1m/3FviJWceBLWoxN7VwoAV74tAx1gEXuac1PaEHu4QVxarSv14gc+24rLcjYyUn1E apglzkEklvbm/vTYseuyXiDeAbH6PnNxVsqms8lQR0kykEZN4cgLMgl4jOiyFYddPwKU 0T1ykuGk/edQJ5zz4nBlLMm46To6PLh34PxsTSEk4Ebtt+oZHBhYA52FHlGcSbbTXHQ6 uovQ== X-Forwarded-Encrypted: i=1; AJvYcCUpXaRSbPJ8ruA8Ui1mdB2IrdqIhlcqMBl50tkODEcLLGa7oDxpBB01/dghzx0+fty9J1H4G/nbF+uBbd0LE9Q=@freebsd.org X-Gm-Message-State: AOJu0Yyvt7UY6N+fMPLgDt+pAApZCOJ8TRV5EwZQQjjVF7w4S6AwEsYS 5jrVoRFQBvw0mNqUUGLT45eVrX6YxKrYsAcCQYXIewT7N7Vy9R0EosIf1k/Ue3uok8OBRxZUkfh F1XmXB4kcrVts/mA/WZoNLJdrInR5K1iZ5EKilGpBtGed5ksrULeSWJo= X-Gm-Gg: ASbGnct1b06h63ib64XiNilFRcAwR66bHO8RRpuoK/HZoYOoKX3N0AZq5EMD5QbPwJY fAiy2KlqQwfsLr69Cy7gXYX9jQbsSgPCE40iNx+OOm5bJQM81lH9T1gW1bxPzZgJCa49grWlXtG Bn0m6TJ8v6bLSJRMooNdAVpFX28k1efjnf3LVb4hHfsnMDrPDcrxY6gYedHd9FM5HQ9mHZIpIJ+ zysVV+rj1eEGxMClg5Ho0LSpwLTAKrtmNwmGWZmrCMxXMmnwlxViVXwE4Vnr34yJjepFoE= X-Google-Smtp-Source: AGHT+IEwW+ngk6Jv8f4/OJl2ahFIPKzeR/+SC4mJbUCuPB/5m+rRvyz46SLeKW9bk+UrjuSrH3q7Z9agppVZX3+Khe8= X-Received: by 2002:a17:903:1211:b0:297:dabf:9900 with SMTP id d9443c01a7336-29b6c0aec00mr215592895ad.0.1764126008388; Tue, 25 Nov 2025 19:00:08 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> <86h5ui7qd5.fsf@ltc.des.dev> <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> <774F9B09-B506-4F8E-B293-CE705F64B77A@ketas.si.pri.ee> <1497323956.336174.1764124966236@privateemail.com> In-Reply-To: <1497323956.336174.1764124966236@privateemail.com> From: Warner Losh Date: Tue, 25 Nov 2025 19:59:57 -0700 X-Gm-Features: AWmQ_bmGbrpB8ar0-VJ2cCTketD-yBIpP8Gezg4Z2xVbU9kcNX5Bfm_svaMsoaw Message-ID: Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) To: Mark Linimon Cc: Sulev-Madis Silber , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000011bcb70644769881" X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dGPSG3xS7z3DyM --00000000000011bcb70644769881 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 25, 2025 at 7:43=E2=80=AFPM Mark Linimon = wrote: > > On 11/25/2025 8:05 PM CST Sulev-Madis Silber < > freebsd-hackers-freebsd-org952@ketas.si.pri.ee> wrote: > > > > the amount of time needed to battle with dev tools should be instead > used just to dev stuff. > > I understand your frustration. > > But while this is true, there are ways to use git that do not > actually require this level of effort. > Yes. that's why we did git arc. With it, the level of effort is quite low. It's also why we're working on getting a more integrated solution so that we can review patches off a submitted branch more easily. github is a stop-gap, at best. So yes, git + git-arc + arcanist + php-the-the-right-version(8.4) is a bit much to install, but it works well enough that I manage 100 branches with it. > I am _certainly_ not a git expert and so I struggle with it, so > I am not the right person to give you advice, but IIUC you are > having more difficulty than most of the other contributors have. > OTH, there is no bad intent here. Please take these into account. > Yes. It can be frustrating to learn the 'paved path' that we have. And I'll be the first to admit that 'bushwhacking' a solution is going to be a very, very hard time. One that I'm afraid I can't help with since it takes a lot of my time that means I can't help a larger number of others that are on or near the 'paved path.' I'm sorry. Warner --00000000000011bcb70644769881 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 25,= 2025 at 7:43=E2=80=AFPM Mark Linimon <linimon@portsmon.org> wrote:
> On 11/25/2025 8:05 PM CST Sulev-Madis Silbe= r <freebsd-hackers-freebsd-org952@ketas.si.pri.ee> wrote= :
>
> the amount of time needed to battle with dev tools should be instead u= sed just to dev stuff.

I understand your frustration.

But while this is true, there are ways to use git that do not
actually require this level of effort.

= Yes. that's why we did git arc. With it, the level of effort is quite l= ow.

It's also why we're working on getting= a more integrated solution so that we can review patches off a submitted b= ranch more easily. github is a stop-gap, at best. So yes, git=C2=A0+ git-ar= c=C2=A0+ arcanist=C2=A0+ php-the-the-right-version(8.4) is a bit much to in= stall, but it works well enough that I manage 100 branches with it.
=C2=A0
I am _certainly_ not a git expert and so I struggle with it, so
I am not the right person to give you advice, but IIUC you are
having more difficulty than most of the other contributors have.
OTH, there is no bad intent here.=C2=A0 Please take these into account.
=

Yes. It can be frustrating to learn the &#= 39;paved path' that we have. And I'll be the first to admit that &#= 39;bushwhacking' a solution is going to be a very, very hard time. One = that I'm afraid I can't help with since it takes a lot of my time t= hat means I can't help a larger number of others that are on or near th= e 'paved path.' I'm sorry.

Warner
--00000000000011bcb70644769881-- From nobody Wed Nov 26 09:45:15 2025 X-Original-To: freebsd-hackers@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 4dGZRn309Lz6Hn69 for ; Wed, 26 Nov 2025 09:45:25 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dGZRm4RfJz3thj for ; Wed, 26 Nov 2025 09:45:24 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 5AQ9jFl2005211; Wed, 26 Nov 2025 18:45:16 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1764150317; bh=KzbsEBNhK/ivla1tFv7N9eGNc9lOxIs9D+2V9m6I5xk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Sb25IwQh8zQZ9wTu1fghAjpqLWSam5c7vRWXEvktxIg9rW41ShpM1loOgRCVt5av3 ealOXYMjxDRopEYwkJ44C33khxBjB1Zc/HUEYSuvW1gtBhgva9JbLJO04yjBN7Q/bY ECleVwJr3eh7popWITIiq7pcbKGAhs25Z5KvtUHY= Date: Wed, 26 Nov 2025 18:45:15 +0900 From: Tomoaki AOKI To: Warner Losh Cc: Mark Linimon , Sulev-Madis Silber , freebsd-hackers@freebsd.org Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) Message-Id: <20251126184515.4fe1ec7820f244deb428a2a9@dec.sakura.ne.jp> In-Reply-To: References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> <86h5ui7qd5.fsf@ltc.des.dev> <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> <774F9B09-B506-4F8E-B293-CE705F64B77A@ketas.si.pri.ee> <1497323956.336174.1764124966236@privateemail.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dGZRm4RfJz3thj On Tue, 25 Nov 2025 19:59:57 -0700 Warner Losh wrote: > On Tue, Nov 25, 2025 at 7:43 PM Mark Linimon wrote: > > > > On 11/25/2025 8:05 PM CST Sulev-Madis Silber < > > freebsd-hackers-freebsd-org952@ketas.si.pri.ee> wrote: > > > > > > the amount of time needed to battle with dev tools should be instead > > used just to dev stuff. > > > > I understand your frustration. > > > > But while this is true, there are ways to use git that do not > > actually require this level of effort. > > > > Yes. that's why we did git arc. With it, the level of effort is quite low. > > It's also why we're working on getting a more integrated solution so that > we can review patches off a submitted branch more easily. github is a > stop-gap, at best. So yes, git + git-arc + arcanist + > php-the-the-right-version(8.4) is a bit much to install, but it works well > enough that I manage 100 branches with it. > > > > I am _certainly_ not a git expert and so I struggle with it, so > > I am not the right person to give you advice, but IIUC you are > > having more difficulty than most of the other contributors have. > > OTH, there is no bad intent here. Please take these into account. > > > > Yes. It can be frustrating to learn the 'paved path' that we have. And I'll > be the first to admit that 'bushwhacking' a solution is going to be a very, > very hard time. One that I'm afraid I can't help with since it takes a lot > of my time that means I can't help a larger number of others that are on or > near the 'paved path.' I'm sorry. > > Warner It would be nice if arcanist does NOT conflict with archivers/arc (/usr/local/bin/arc conflicts). If it was, I could have been gone the way git-arc. Anyway, nvidia driver ports I'm currently (actually) maintaining are trivial to upgrade normally. So the most complexed way are not so often required. -- Tomoaki AOKI From nobody Wed Nov 26 09:48:43 2025 X-Original-To: freebsd-hackers@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 4dGZWj4bnWz6Hn8c for ; Wed, 26 Nov 2025 09:48:49 +0000 (UTC) (envelope-from freebsd-hackers-freebsd-org952@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dGZWh4460z3vdy for ; Wed, 26 Nov 2025 09:48:48 +0000 (UTC) (envelope-from freebsd-hackers-freebsd-org952@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b="M/HjzPak"; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-hackers-freebsd-org952@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-hackers-freebsd-org952@ketas.si.pri.ee X-Original-To: freebsd-hackers@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1764150524; bh=0QCPAkaz4bioIEquiwsptHc7KbYiyXED9wAOPt2EagE=; h=Date:From:To:Subject:In-Reply-To:References; b=M/HjzPakDSlaPo9m4WOXmaxKF2m6aYv/MSAwCeELkh3I3AvTu7R+v7VJVKChtGdQT wkaG4t76uF38jwqI05wFdW3CThR/1jnO3O5Fimlgeoqu+VtFx1Oj4vSa9BVM143rPt rErtXJB1RScEcnJs4Y3UBa3MLPerQnCJK1Bj5QmXPmt4tpG6QzSrIZIK25ucdHQx2i qs83ZZoalJbQF12J83vmAJzqPAoQVP6I5zn2auqRYJagZH26Qk4ivfwUPdZUJhW0Eq k2AwL8XwXRWTz7a4cRmfcGiUZ5ZREizbk7Pai02tmUFb476bKmLP+Sp6LLxBAu0vyO iup7s5zwcowO6ZglPIk871TeQuY2I0b6l2NKh3EXOP1q80wf8qnjJVYvJ8T7mNeZND hbPNewWln9fDqfQle8PUQlsXC47aPpWS6tdZZt+gc5NISgx4vEu0WeAWTzomlGgch9 MNOug4JS7UG+WdMUo9cfqgHb2qGxrycwR0f6RDCUnNpoDuQf3oPMHrsJrQN8MXHhZk E33oB+CgObkL2kt/qAIKEtVap2lqrrFG7TUqIU9xZw0WwDNkNSgsZgKoV5sQ5e9Ya1 Us2031PUtPnyUgXxKQCgKC4cTQ/K/+2PjL8WOeqEMN6Ab2BuG/4vTitmxBYT1IwUs5 f52JB3fCz6cnFGmReyvZABP8= Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id C67E35B76F6 for ; Wed, 26 Nov 2025 11:48:43 +0200 (EET) Date: Wed, 26 Nov 2025 11:48:43 +0200 From: Sulev-Madis Silber To: freebsd-hackers@freebsd.org Subject: =?US-ASCII?Q?Re=3A_=5BPATCH=5D_df=3A_correct_BLOCKSIZE_han?= =?US-ASCII?Q?dling_for_-k_to_use_1K-blocks_=28290710=29?= User-Agent: K-9 Mail for Android In-Reply-To: References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> <86h5ui7qd5.fsf@ltc.des.dev> <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> <774F9B09-B506-4F8E-B293-CE705F64B77A@ketas.si.pri.ee> <1497323956.336174.1764124966236@privateemail.com> Message-ID: <6B77F3D4-C55D-4C63-9537-EBC151AFA35F@ketas.si.pri.ee> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: + X-Spamd-Result: default: False [1.15 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJ_EXCESS_QP(1.20)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.959]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; NEURAL_HAM_LONG(-0.29)[-0.288]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4dGZWh4460z3vdy i did ( git diff --color sysutils/u-boot-master/ sysutils/u-boot-orangepi-zero-2= w/ sysutils/atf-sun50i_h616/ ; git ls-files -o sysutils/u-boot-master/ sysu= tils/u-boot-orangepi-zero-2w/ sysutils/atf-sun50i_h616/ | xargs -n 1 git di= ff --color /dev/null ) | less -R i mean, just the sheer amount of manual work=2E=2E=2E an alternative is stashing stashpopping stashpushing headresetting messing= whatever? i mean oneliner there and it's scripted better version does allow me to ey= eball the changes and possibly submit the above change (uboot for h618 boar= d) but it only works nicely from the top of tree i mean git does include many commands that work on untracked files on wd, = so why not have special flag to git that also shows untrack? i mean status = shows them!!! maybe git feature request here this has taken all the fun out of actual task which was hard too, but now = the uboot port is installed at least google shows i'm not alone=2E nobody wants to change their repo locally ju= st to get diff out of it, then immediately undoing all changes=2E hopefully= =2E none of those changes were required at all=2E none of those frustrated = people wanted to touch repo at all=2E i'm assuming they were also some cont= ributors to some project and wanted to have submittable patch back in 4=2E* times we had special port submitting command=2E it did not r= equire magical filemessing=2E i used that and it worked=2E now it's gone?! as for backupping the untracked changes in ports tar cJvf sysutils-atf-sun50i_h616=2Etxz sysutils/atf-sun50i_h616/ was much simpler i mean i might as well just tar all new or modified dirs up and give to so= meone else who's willing (why) to engage in gitmessing=2E probably with dir= ect ports commit access to make all those changes, maybe create review diff= and then commit & push and this the most actually user friendly vcs existing=2E=2E=2E? From nobody Wed Nov 26 13:19:41 2025 X-Original-To: freebsd-hackers@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 4dGgCD0Dyrz6J3M6 for ; Wed, 26 Nov 2025 13:19:52 +0000 (UTC) (envelope-from freebsd-hackers-freebsd-org952@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dGgCB4HXsz4KMR for ; Wed, 26 Nov 2025 13:19:50 +0000 (UTC) (envelope-from freebsd-hackers-freebsd-org952@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=DRjXTHNx; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-hackers-freebsd-org952@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-hackers-freebsd-org952@ketas.si.pri.ee X-Original-To: freebsd-hackers@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1764163182; bh=C5TBV/Gd+gldHvI0hf+C5BrcEOpampFl6zS0Qvzw/zM=; h=Date:From:To:Subject:In-Reply-To:References; b=DRjXTHNxFt9NYpooBYZGEBpJce4CcwOj6KMKTfJUJmJOxm8q9yfZOKGj1QX1brSkd 1cIvduSuSirJt2C4yzdJVs7s9l6cwF/F/TVZi6lyGxyauOszYyd/4kxAvCpYPiyiaP w1trqFV5m97uy8qxMSA+dCP9iGGAogUKRLQAHAngu9V9VTpTJ3vIOFP4WrRzEB+7nv AwLg0DNR8ru01LT5tggPAts/ZEv9X1cLFlRhmuWJCEENZLNsVm853tsXOFkd6mwU/f wtJ3569jemNyafvCHKO/DhLNpd7tfbpecRvm/UdIPswmPVxRqrhazzFVzOPOR7zVvK yhXnYk0ycMZ+X4Qw3SSdRcuXfPJe4A4nxc8TWNtbUniHOopTPWMCTjp0uojEujSRcB ccA8jrOzHNkbJMyjAwenIfZDYZxVjS/1qyRxEMg9L8i4swV4yR2OTrB1wLsog/USxl xs+Er8PmdAStvri88Mj+ZymrG/B8Hi4BDL5+IAWgX1k2oJMjW+6B3EcLCQEwDEOKUz KzISLto+XWyvuZCQVpEsKsdMOH6xzekbE14zIoA2qnP5qxE5vrvAf15v9jKqTIj+hh SL8s4GZVPNUEvgwAFl8A3vYz70fi/F1IUJ4DeJT5y3gGBwd8a9gDJxBxQuXSx2gsmm RqCq4OV3dSQoqnG39i97/dCc= Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id BB1C35B9704 for ; Wed, 26 Nov 2025 15:19:42 +0200 (EET) Date: Wed, 26 Nov 2025 15:19:41 +0200 From: Sulev-Madis Silber To: freebsd-hackers@freebsd.org Subject: =?US-ASCII?Q?Re=3A_=5BPATCH=5D_df=3A_correct_BLOCKSIZE_han?= =?US-ASCII?Q?dling_for_-k_to_use_1K-blocks_=28290710=29?= User-Agent: K-9 Mail for Android In-Reply-To: <6B77F3D4-C55D-4C63-9537-EBC151AFA35F@ketas.si.pri.ee> References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> <86h5ui7qd5.fsf@ltc.des.dev> <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> <774F9B09-B506-4F8E-B293-CE705F64B77A@ketas.si.pri.ee> <1497323956.336174.1764124966236@privateemail.com> <6B77F3D4-C55D-4C63-9537-EBC151AFA35F@ketas.si.pri.ee> Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: + X-Spamd-Result: default: False [1.14 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJ_EXCESS_QP(1.20)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.945]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; NEURAL_HAM_LONG(-0.31)[-0.312]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; RCVD_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4dGgCB4HXsz4KMR in order to not completely lose my mind, i created this: ---------------------------------------------------------------------- #!/bin/sh -Cefu set -Cefu diff_opts_full=3D diff_opts_no_color=3D case "$*" in full' '*) diff_opts_full=3D-U1000000 ; shift ;; esac case "$*" in nocolor' '*) diff_opts_no_color=3D--no-color ; shift ;; esac ( git diff --color $diff_opts_full $diff_opts_no_color $* for file in `git ls-files -o $*` do git diff --color $diff_opts_full $diff_opts_no_color \ /dev/null "$file" | cat done ) | less -InR ---------------------------------------------------------------------- minus the weird options and their required order, it even does the job, if= you also remember where to do your diff from but it doesn't touch the repo at all=2E i don't know why getting diff woul= d need local repo messing too workdir changes are easy to spot with standard commands, but if you start = doing those other ops, how could you ever get it back=2E and then you can't= get rid of repo too as your local changes are somehow stashed into bowels = of it it's as if git assumes remote repo cloned out has write permissions if no, then only way to properly work is to bring repo to about to commit = state or even localcommitted state and then back changes out again=2E well = if you committed then you can't really how, just hooooow, do all the devs work on git repos if they don't commit = from repo? all that makes me brain hurt and back then we had port submit from porttools which portlinted the new d= ir and sent it as shar with send-pr unsure if it was hard to receive them that way but in nowhere in that step= i needed to curse bucketload of profanities to any current fbsd vcs=2E iir= c it was either svn or still cvs back then it also had csup for low effort src syncing=2E losing your mind was not re= quired and also i realized that arc also doesn't like untracked, etc, so i battle= d with it until i found a hack i have absolutely no idea how people could ever contribute like this=2E yo= u tell that there are other ways=2E must be, as noone really does this how can it be that it was better back then=2E for me, as starter=2E than n= ow, as "continuer"=2E=2E=2E From nobody Wed Nov 26 14:16:21 2025 X-Original-To: freebsd-hackers@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 4dGhSL5v42z6J6tJ for ; Wed, 26 Nov 2025 14:16:18 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Received: from sonic306-20.consmr.mail.ir2.yahoo.com (sonic306-20.consmr.mail.ir2.yahoo.com [77.238.176.206]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dGhSK2VXpz3Dj5 for ; Wed, 26 Nov 2025 14:16:17 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ZYwjqbqn; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of anthony.pankov@yahoo.com designates 77.238.176.206 as permitted sender) smtp.mailfrom=anthony.pankov@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1764166573; bh=DKzJrS/R/fz+bU1qxtL67sbvTBwbdQeRjov5ehW5mq8=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=ZYwjqbqnD4fdN29M2/HwUHTj8yAxBhiOf5TByfTYDb0FF0N3FLcT3wetufrTVTZM97vCzspjPFcyQUigoSdpiEEEqXmHbRsolkUZsScXHei+eo9/faAsg97szFYsh2ULay8zsHyM8vNrkKuvxXcCOo7fTTxHcElk73hp3xVnm5xvXqWFnlCyJOHbBjXeQfeLmlzRCpbepM9mfK0wHgWa8TzTkorEbDXWPdGQa0umFzo+aWqCQSkOKG/CmvfwOv/E2lMXWLHlaUjygc5RMxOFBmLrwsjfpCyl+ENBwOJd4R35ZEftwNzfvaFpXlGdMEBDm32rWfPM+1fqj74A96OqrA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1764166573; bh=ipFzj6oTpjBS3RywS+txXXiTWVxeSE7r1R91lcdmlyo=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Ev8P7X7raCLYw/1exIUDNVkquMtEp5S1faEY6639dIscK0hkX2nWebIJIP1vYSqCs0s/HwLne8WSYB93Es68y16rtuEb9eGgpIMUzvAap8xmaUHBse2cPQlDPk8ITtbIcyUUS3gCp7+A6Ac+lJgqVFgYFPRxbKGScdXf2+ZkwzTy6cKyv1fFcGLFccRhMeQiIH45ha9+1DO8IaNdcGvvHb3Ddioy1lQ6AhZBin6BmWT57M8ag9TR5H2nm7Mwe/XCrojYYehz7sH6dQ6PjJ2Fhu4E4Vn/Z5VyfrM8gQlsrXC5bwO9txTjuuesePBY+ZVPjrwebgeqQRMphJ5AjpzQiQ== X-YMail-OSG: 9pQy01UVM1lPutyoOR6Ia2RPVAdbLW1PjaY3MkUKHybuqxIbi5AGe08_GfeR9jg R_Bhahppg9XkxX_IhG5TVgxpE8b7IdrAlQXKBtjjkHYzGFMBNiIktlwpyqfgUZrJIzV9RbdR8qVs 9rBJUDfgKfY0gtA4jWoBs_OpqPDsQcSe70eZz.SpZO37.6kfMWkoyQOt99COI4YVjQ3NoKjRRvbN zR4_j5CrBIgcNJ57GYGpsgsgRwXV_EFMJwjcx1OSwxkhHIVKpiVftyUeTwjxFlHxqHhNNPkXsA6O 1iWZ3n1gS50z4a4rJiGjgx2Zywctfnevhl2NiSXoPZHMDbbVBV7QM4Sy9FYd44qXapZQ8Id5jGnC 1s4ye1H8JPkYdCD4nxZbcxzdq4UeZSzW3FosNig1Asfcm5klERgwQV.kWqAJ7xD6iRj5oZ7oibLL jkvCKwE.7id98YAigEdRQcfdD9IG8bL.m43EKpyjm8b0xngrg9veMLmA1tYjTEJVLgipMdqKkaBs s4_mzFx_2mNiRhPEu6PhIOWKIZKzvSR6aWAGC.v_tGblmVSZxEebL7ODdyid3QszpllUMgOT5glx gExDYsp1om8qIhH2QRTDsowMmH0fy.z8046V4XibD13VqsVGVdgNH.mjrCNVJRS6lLXzG8pFCYxM hE9K9gMj3kJdrn1THAwabjPxBiizqzeLaNTam_cLZTn574RA5yo6hXcSXLnZIlcDfizyXBz7i8.G 1AqbV72j__HKsjKNpklM2LIpli.RCP6Jmrn8V8by9fY6aA.LTIRJYQikqtfRax41v2UqOwCmSB._ S46Sg6n2L6WzgL6V7PqZG.kcVpatje6ZdtUjFms3hWfncG8lS32sDwM2Fgl_YsMraFiMk2ZBEK0U FFjj3fbvHP5WxiO5TrgR_PlJ1cOomQVrACL6N.29eY2PyKwaxRSMSDrd0sxozhYlvePKgj0yf..7 OvZg9h6_7Xf9tWlBIcyp_lmyvYbt1f_bjcng9m2i0rFOav5kdM8YSKnaGEfl3mhRDX3iU._mqrmf h5hkTTL.QHUGynEYXByIRRo1w7XZ_a45einYtgbcGR47FjEXW9Zwm6c3SpnBFwzqAJv0ZGRr8abJ m.ugHlxXgcqqKr8mxlcWUExBGpSau1cQzXRhg8stcjhmtqiizI8wjfQxJigSyqlYin.PEp8_bhKM lw2F6WFeoN4KmYyA.ml0l1maJ.wMSgmDPiFA45HCQ8ebLLelQrGBRrAyeyLuYmPcbk5rS7ydIwfO FipFnkUm7rZr7B_xOX3VwA6B2gI0umDIbh880wsa_hSoM4AYatY3aDzjfV.JaAEFdn_TZyl5h4rc 2nosyPfu48WetRVDLsO40b6t8dIkOoLE3YSc1nFCQbROT2UmppgBJKYoBmA0AaV0tpKoGE8vqjsK sF11XTNjFjcF.9RQSe3YXZnCn550Busge.aPOAc3.sUz3kDORnhGcCwYfmFyDtClKP0Le92boRXp zNE3Vd4w3JQJ7lCa.w_ParW3zmhNMRWKTZONsf35OcV6tz2oWXZLtEpJVJaJkyBKev_EIAtLCDni REhmFlDi8xRMz6Ah7XqOonDyUFK7_.Bw4lOD_N4zXN1ti346oI9advFZVieCupSfjGMmo.WlbtOp ZmftJU.MDAEBsRI9wmfWuQuOynQ5yQfjoyKc5NWQHY3DJYr2CRza_OtIkRmgR8.4rg2Ni9P62Zsr hSs3Ttz8kjBtdKurDdLod5PcZXLWquxBRwkV6zSIeYC1GrVQ9jEl1kp6tNdEtAUHVo4JyIQ1ypb8 _2JgMXbgWsdnL7Ed5BzorS_KLl080Uohpwfwri2o1DPLonUaVRxCoSmJI.V36f52IBkRzB4eNGlu GGpi6oitgYif4gi0SCko_Mlrp.X5DrK.0iJ6GxvIaZVmaLEBk6.xGXuRrezCXuSf9dv3zrRP5a_D w4S0qX3QnM_vki7tmEvrHTOxCge2LuVD3Sj9eESJkXs34U46VIMuvbbCfyHLBslyEFVachJk8I4H XLqAo.taFT8PgkdQLX0V4FaBtvepHR5FKyeBwALtjo2bs2WkwnGi3CuSziblSOrFG8AzTAlM3OgS Dm0rfmLaKk9SJpRoo37DLP_2j5vDwuT68Y8kCx4Fyw_U01QDEZpuB_UtZW0VEv6Tas4qcGd_4e6N 5VOXcBTHXWIxArCty0QZiPTxsUUTPvpUuWKYS3koW3_fAthmHXLjXsxOTSFx2NtcmRPRj5eiaOZ9 eCw-- X-Sonic-MF: X-Sonic-ID: 23e6bfa3-bd0e-4530-977f-0e027d69969b Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ir2.yahoo.com with HTTP; Wed, 26 Nov 2025 14:16:13 +0000 Received: by hermes--production-ir2-76fb978d99-nzs7q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ef957473f18de726cb8542d9a887b6eb; Wed, 26 Nov 2025 14:16:09 +0000 (UTC) Date: Wed, 26 Nov 2025 17:16:21 +0300 From: Anthony Pankov Message-ID: <458400081.20251126171621@yahoo.com> To: freebsd-hackers@freebsd.org Subject: any way to recover from I/O hang? List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <458400081.20251126171621.ref@yahoo.com> X-Mailer: WebService/1.1.24794 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: - X-Spamd-Result: default: False [-1.70 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_SPAM_SHORT(0.30)[0.296]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:34010, ipnet:77.238.176.0/22, country:GB]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[77.238.176.206:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[77.238.176.206:from] X-Rspamd-Queue-Id: 4dGhSK2VXpz3Dj5 Recently I'm again facing a situation where some UFS (?) error on one partition forced me to reboot whole server and interrupt people's work. As I understand the brief is: Reason: A process in state 'D' (uninterruptible wait/sleep) is blocked on an I/O operation (e.g., waiting for a network file share, a disk operation, or a device that is no longer responding) at the kernel level. The process is not awaken to handle signals until the condition it is waiting for is resolved. Solution: You cannot kill a 'D' state process with any signal, including SIGKILL (kill -9). The condition must be resolved (e.g., fixing the network connection, waiting for the I/O to time out, or potentially unmounting the filesystem with umount -f if it's a mounted network share). In some rare cases involving buggy kernel code or hardware failure, a reboot may be the only option. In my case there was a jailed samba which share one ufs-formatted partition. The samba processes hangs one by one and sharing has stopped it work. There was no message in log. Geom reported no errors. Disk's has no error. It seems that there was some introduced inconsistency in UFS. My thoughts was to stop/kill samba, remove samba's jail, unmount partition and do fsck. But 'jail -r' exit with something 'rc.shutdown exited ... 9' and left jail running. pskill -KILL for samba processes say nothing and do nothing. 'umount -f' say 'Device is busy'. Various utilities such as 'df' hangs. So I forced to shutdown the server which has other important and workable service to resolve the situation. I wander is there any way to treat such a cases? May be 'umount -f' can have more power... P.S. Previous situation was when I do simple (as I think) experiments with ggated and have forced to reboot server when 'mount' hung. -- Best regards, Anthony Pankov mailto:anthony.pankov@yahoo.com From nobody Thu Nov 27 04:58:21 2025 X-Original-To: freebsd-hackers@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 4dH42Q5Jvwz6JPmj for ; Thu, 27 Nov 2025 04:58:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 4dH42Q1FMXz3VXy for ; Thu, 27 Nov 2025 04:58:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-343806688c5so357015a91.0 for ; Wed, 26 Nov 2025 20:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1764219512; x=1764824312; 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=CcDYq4dZ91rg7BGQ8PB3iaFVIPUPEd+OixcgyuEw7Wk=; b=igRTMpvLpcK2rYEy2aqfPmFc/5s8Iy0ZHYbvWJ6e1HsJtiRSDYnr+s6RYgouOKcd5C ZtPPeGac5CtJJQwcY9Kude/XjQr0jcmlBlAER7tLR4Rdw0hrlzPvIK8cvCmM/uXdPzwl D4lLejJsYsZko+7Z0rfvjL3WGx+ojm8GOwUgOXn0LG0nIKXEGbt+kcVLUOpEhSbDnMwu PrEsXm9uuRUbdfw8nS9c2FCqOiK+APiiA8crD+qPQBzLuDqzA/kCdZ7aew0ewPmG1xex RDP/f2rHIaD5S1SvHCPIGkNa5abXIC3EqYF2WFz1kRTrP0DI3bPsd2Octge1+HJHULbV kbRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764219512; x=1764824312; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CcDYq4dZ91rg7BGQ8PB3iaFVIPUPEd+OixcgyuEw7Wk=; b=ffpXBoUY0qYlgr4usecs977HkSciarlFtheORQz4A1w5bTHg/0K4CJAWV1ZfU8wjzm NLDAoxvLUc/XQkib5H6YoB6C2eGs5eU0qo45aDzkJEt7fiVUHeoKqxuWxgBBP8KZnAt4 9aRUjwzjp8ROjTBqYPO2bvNF+OZfBX1kK83+547Wyw33bj3L0Cw2VVTTHhrRrc8Ai1uR XqlLJXvk6r3MR7UZX/dbYj7LH3OWmboiGKPInbO0foUhkDJ8CMbhV3GvifqMurzkziBy zL5A51cct4SRDWj5rhLLNQpuY9U8+n6ChNyszVoko0QadstDSoPt7BXrD5lgMADEe/Hm t2Gw== X-Gm-Message-State: AOJu0YzEEC9bPwxqqJn9bG7LrLLjz1kDKHHFs5c8zSPGHRWPAbGjt58Q v91tmrOwuRGYj7pf6a28WME1lK1huIZC8X9FSgtMUCf5ZetxMx2VKdlL1DybO1nM957o4WmHcZx GBfS4IODNnVe76Y7NYCSAfieVlSn4Rdbx/AQwzHGPcZoWYRLXOHfj X-Gm-Gg: ASbGncuiNN0njgpbe7yjq3f2ICWcEHjiUVDpLTrmD03DHHl+EjCmLnLtG1QdesmUETo +cz0J/Df4IKWNLJsgyS1L2KJXujfHsWJdmKcAgayIfUWr1duBwEeDOde+CcY+QRj1ebibClDu46 o0/PevIE90pYWozB+t9Eym2d2J8qT7ErlAtfRwX6EZNDQ8639GsoPkjKSHAza+oqzDmR2XewF3o EeopEwOHgfREdRnPRTPhY+z43S7detM/ROlJDlqfwazoSOaIwxwZVSncDI6lkBEQHfb430= X-Google-Smtp-Source: AGHT+IF/21S6xUsF4N10b2fBkgOEgRa/PwVfIhPuBLS67BNMkt7A1Rtd+N4cW5Geh6qbg+PPpgf8W1I0GoCN/foY/x8= X-Received: by 2002:a17:90b:1f82:b0:340:a19f:c25b with SMTP id 98e67ed59e1d1-3475ed50999mr10123091a91.24.1764219511916; Wed, 26 Nov 2025 20:58:31 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <458400081.20251126171621.ref@yahoo.com> <458400081.20251126171621@yahoo.com> In-Reply-To: <458400081.20251126171621@yahoo.com> From: Warner Losh Date: Wed, 26 Nov 2025 21:58:21 -0700 X-Gm-Features: AWmQ_bllA1m9VHb09FaIV8FuQmldQOUNxO9GzwP0Hh283mcjvNhTyaAGWDWFVuo Message-ID: Subject: Re: any way to recover from I/O hang? To: Anthony Pankov Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000050557006448c5d4b" X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dH42Q1FMXz3VXy --00000000000050557006448c5d4b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 26, 2025 at 7:16=E2=80=AFAM Anthony Pankov wrote: > > Recently I'm again facing a situation where some UFS (?) error on one > partition forced me to reboot whole server and interrupt people's work. > As I understand the brief is: > > Reason: A process in state 'D' (uninterruptible wait/sleep) is blocked on > an I/O operation (e.g., waiting for a network file share, a disk operatio= n, > or a device that is no longer responding) at the kernel level. The proces= s > is not awaken to handle signals until the condition it is waiting for is > resolved. > Solution: You cannot kill a 'D' state process with any signal, including > SIGKILL (kill -9). The condition must be resolved (e.g., fixing the netwo= rk > connection, waiting for the I/O to time out, or potentially unmounting th= e > filesystem with umount -f if it's a mounted network share). In some rare > cases involving buggy kernel code or hardware failure, a reboot may be th= e > only option. > > In my case there was a jailed samba which share one ufs-formatted > partition. The samba processes hangs one by one and sharing has stopped i= t > work. > There was no message in log. Geom reported no errors. Disk's has no error= . > It seems that there was some introduced inconsistency in UFS. > My thoughts was to stop/kill samba, remove samba's jail, unmount partitio= n > and do fsck. > > But 'jail -r' exit with something 'rc.shutdown exited ... 9' and left jai= l > running. pskill -KILL for samba processes say nothing and do nothing. > 'umount -f' say 'Device is busy'. Various utilities such as 'df' hangs. S= o > I forced to shutdown the server which has other important and workable > service to resolve the situation. > > I wander is there any way to treat such a cases? May be 'umount -f' can > have more power... > So no errors from geom? Or from CAM? what's the underlying storage hardware? And what's the wchan / straceback for the processes in 'D' state? And do you know the location of the file that's waiting for I/O? There's a number of things that might cause this, but they typically are noisy about it. There's a couple of deadlock issues that might cause this, but getting some more information is needed to understand what might be done to mitigate or prevent the deadlocks. P.S. Previous situation was when I do simple (as I think) experiments with > ggated and have forced to reboot server when 'mount' hung. > I assume ggate isn't involved when this happens now, right? Warner > -- > Best regards, > Anthony Pankov mailto:anthony.pankov@yahoo.com > > > --00000000000050557006448c5d4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 26,= 2025 at 7:16=E2=80=AFAM Anthony Pankov <anthony.pankov@yahoo.com> wrote:

Recently I'm again facing a situation where some UFS (?) error on one p= artition forced me to reboot whole server and interrupt people's work.<= br> As I understand the brief is:

Reason: A process in state 'D' (uninterruptible wait/sleep) is bloc= ked on an I/O operation (e.g., waiting for a network file share, a disk ope= ration, or a device that is no longer responding) at the kernel level. The = process is not awaken to handle signals until the condition it is waiting f= or is resolved.
Solution: You cannot kill a 'D' state process with any signal, incl= uding SIGKILL (kill -9). The condition must be resolved (e.g., fixing the n= etwork connection, waiting for the I/O to time out, or potentially unmounti= ng the filesystem with umount -f if it's a mounted network share). In s= ome rare cases involving buggy kernel code or hardware failure, a reboot ma= y be the only option.

In my case there was a jailed samba which share one ufs-formatted partition= . The samba processes hangs one by one and sharing has stopped it work.
There was no message in log. Geom reported no errors. Disk's has no err= or. It seems that there was some introduced inconsistency in UFS.
My thoughts was to stop/kill samba, remove samba's jail, unmount partit= ion and do fsck.

But 'jail -r' exit with something 'rc.shutdown exited ... 9'= ; and left jail running. pskill -KILL for samba processes say nothing and d= o nothing.
'umount -f' say 'Device is busy'. Various utilities such as= 'df' hangs. So I forced to shutdown the server which has other imp= ortant and workable service to resolve the situation.

I wander is there any way to treat such a cases? May be 'umount -f'= can have more power...

So no errors fr= om geom? Or from CAM? what's the underlying storage hardware? And what&= #39;s the wchan / straceback for the processes in 'D' state? And do= you know the location of the file that's waiting for I/O?
There's a number of things that might cause this, but they= typically are noisy about it. There's a couple of deadlock issues that= might cause this, but getting some more information is needed to understan= d what might be done to mitigate or prevent the deadlocks.

P.S. Previous situati= on was when I do simple (as I think) experiments with ggated and have force= d to reboot server when 'mount' hung.

I assume ggate=C2=A0isn't involved when this happens now, right?=

Warner
=C2=A0
--
Best regards,
=C2=A0Anthony Pankov=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mailto:anthony.pankov@yahoo.com


--00000000000050557006448c5d4b-- From nobody Thu Nov 27 10:13:17 2025 X-Original-To: freebsd-hackers@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 4dHC1J27hRz6J29K for ; Thu, 27 Nov 2025 10:13:08 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Received: from sonic304-21.consmr.mail.ir2.yahoo.com (sonic304-21.consmr.mail.ir2.yahoo.com [77.238.179.146]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dHC1H52ncz43Nb for ; Thu, 27 Nov 2025 10:13:07 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1764238385; bh=Xo39Aq7fbHE0eZFt6LcfSZKZfq7TunUkfsEpXKNkr/U=; h=Date:From:To:CC:Subject:In-Reply-To:References:From:Subject:Reply-To; b=TJjFWE78oYyHNdeDozL+A9FDtWdWSJnIUZIk6N43RjWeUrgX+UOTbCKXX7P5JeygXaNl1n9h9kUBBjbRGGJAfqKWrMYuDkeZ5OWUYEr/rjdvQvkyLSKhxg/f1B7/UcMnIUqPcw9j59anhEclEDIl6jEceo6aDfMXT8xdNannFaFsJP0wlA7CKsHOgJbFqmiJWH7SNvh7lycBRt78bAQ/0s6MyuS4+QstvcYvE57O7Gvyjn8IbBduzGzcExsaE6gWj9zqAedf7C/SRoKkqa4rVBN2yXs4vG32mSKPzFEOhRAwZdVRrvaaTifSEMXoChk1COB44ZXCFPXSF07/gQQ8gQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1764238385; bh=eW/3nueO9LLwdUJazaVGaREETaG3+rh9gW5XovM67PA=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=qsMlFnYPZ4pVYuCs3XFYmAw8kSdEMiLkOZ+UQsm8wDIh539Bfus39F09NP94d0XzHIUSD91ObFHeaMwf0GiufKRHLnUS9q+qYmyt5vmZgvgys8+Fl+U+RmZD7akJSicRXBYxEBDYyGuX9/FUnQ+MuMakUFOrQw6naNR4PTZgjh/Xg0Tu8b/kDps12piItMR0gTYKZE5oW4zQd8wZjeaT+oZ1milxFnzBrJfUtJlHXQTKz+gtQygs/AyJxGawYkNfG1LJIjQYafrMkJnuhJurCXbWSGdNTdnrZiNCPTG4i0gMbVXHhHDUieilwK1VV3oe92UkkHJmO+NWCW7SM8LEtg== X-YMail-OSG: mbV3.mkVM1mOeTtJTo.Flh4.pY_.PuELk9e3lJNUWd1PmJ8G2_2XP.Ig2dgrIJK JjinTOvzBFQeVx1vvDHT_CjTiW5B4iX2OC_KfzlPEboTcK2GdFmH2kM7BoWPRACEnWDv75fRykXi wYahOjHZr7DDObmGy2HySvXJZURymDsjoqbFqou_8L56roqpw7X5AMfcnuL9SrlhsbGMWPeuPzwR qwKK86mEmEFMlhgejvj2g0wr7vKdJY2XxiU78PmKs.FvLidtQfLWR5Ktjf403g_bv.p5zNJvnEtC Nw4KK5UqO6b6yAyfQTcAgJTBYOZgBP3ep0piZaZgAn_3mdoLEs932gekJI.05B1lE1FP2QTfYfl4 DbhEH0wiWyOpvbN3t8pDhUsk9._ngkjoGuLmjRXKGseTGCBTptZq7G.ac1HAF1n7I5mjo1ApsdT9 Ah5QyZ56QpV_bhXT4ztO0DBQ.TQNrQX3ElSTm3iNZ4yYVNq7c.6uGhpANmWQHZN401mVZehM1f_p _wwm3Di200_fSjv4jUH2mrHbxLLF5YeoigonHf.I9mYlXlpAhsIdI7seLyzPLNhol9M5S6GHNbh5 WVkJufx7ZX602Dgfz1ImiU4UItmLqg8vXz9Q_8R0a1yZMLxbIhA5T3H8hoxoRXlPV8at5Q3kTuPj DfEqvJ_1GW9Taaq62MjOH6mYqzGiF8QYwucvhMoxPZIMTcB_fuP6554dZ54TyM5c3Usq_VzgmheD ga7Su_j95rKqrL.ssi_RI7WARVm9GFWx6Kg93ZqDdFCxLjxoaUnJOx_59HBcalSm4VrdIrCz1lMr p1vmE05YgvyeLMyUry5Pyuhdme8mWJGN4sek5Edio8No.fbFPqZdzQW_OhmQdv5mVDAB0f4k6ieR zP6C7IEiSmVjD7tbCs4TP6wwMKX2U_EvNtpX8bWnKIIuUeQ_QAvzaE5VXVcqBcTqC_q3z_XCNU22 btgrcqDoaoDkSkRpJw3e_UGte70priQwY6kQp9lPAHAhewDbWoorLsaaDGC83rVJ15rkXSUOxD.Q hSPX__9tf4oVypt09sSnxjLBMTb15a1i6R17awHbuw.KdLWn0_UkVtJMI8qJhX83dG6fisH8K3T4 h9kl69dRiLQ2y2bb8YjCkxnsQDmK6b9_nPNBpKNGDseLhWgRJfO5B9LppFN6BUCgnx7tt8C70Gg_ tw1V3WKZb3WIJ1m8TEu.QxXaNdFrSSD9ilCroBaevVBy6amox.mSt5wwnrTMuf46KAD0VuQpnj7E mGKXb0DCh1IqXnkVMWgTtv7HbfqEbgLM0lnKKsbg3tCqCQlhfN_.eBpEVE7k.4Shx2gjS.sJLdLJ lvNaJRGSoOdm.AAtuowQZZjb.OfBnjLBi5R9pRhbXpN7o9pHzzI_8HibwJnzTVIZPt97lO6beZ8u 2_jid0rldZslxXhhgnpex3YhlTDrJh_mqYV3jnAz3VIiOxsCiUC.OjvP72UamyUgMHazSevlx3SH jnosqPCp3Ay51Ig3bY9lphEel09mIOMfpyKTrxVvSSqjNYdntvO79SfPUY0zXFXAa33WIXCAxUgt idRwfv.1gYErMrTnoovVaPxc.vxy9EMfQviBswIB7ZnyDDFdI.64A_E2t3n9ZOWhzDEsbqAmHocU I7pZFJqCnKEJMPjiGIWKuId7NqUwODQoO6NBtg3OrRzck1JHYDbI43thk.AJuwQslAQi4uzYj_D3 JR1cZaSCwcDbvp.oCOoJLZjbQdTLG7rC4nueGK4dIuIitSg_3KBqCVZZxBCdSqG2RbQsdDJj6Twl VJH9CAj2ORZTy9UuVD8ThnbgbWiz47YXOJYgntTDNvxu5gRJ3jd0VWL1Gh54nPWpWLVyyTf184em splifgjr06.XWJ0BNd8ca10M1RTk4DOVn_Wdr1lw1hupmDiPffy02CeQEndyyRbVz5RUxAuA.70N _BaLrhRryh.QA_F8MTSgjrhC9mTWfyJGDdleYBiV5Sx.BwBpVUJILw0NocvJmwFyOzNc8_MlqNJh iqeakznJhm1nsOJIjcWnv0D6O2AVW7DNfWizi.MgBGaFpGllFdqPH97IZBbR5N9wLITfDrUgrT4O 1kcoxfktKV38.A.euUBY80xqMMOwd0McstQGJmZbbUxHubi_GBpKuXk03MknwoQevkzdvko66YZZ 5aHwPiTjpne.dYS4JZpjCcM41r5Fcy4nPtOumJmQEwjtUQQC.NRZDrgp0b7x_XhDppiEIOOUkYIx jQ2WZJZUywyRWrOxf72kNaufO1T0- X-Sonic-MF: X-Sonic-ID: bf9ccae1-ca27-43ef-a4e1-bd14554924c6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ir2.yahoo.com with HTTP; Thu, 27 Nov 2025 10:13:05 +0000 Received: by hermes--production-ir2-76fb978d99-44fvc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 33ff9eb4bf7b94a08d48f71ffcf1b20c; Thu, 27 Nov 2025 10:13:03 +0000 (UTC) Date: Thu, 27 Nov 2025 13:13:17 +0300 From: Anthony Pankov Message-ID: <908785764.20251127131317@yahoo.com> To: Warner Losh CC: freebsd-hackers@freebsd.org Subject: Re: any way to recover from I/O hang? In-Reply-To: References: <458400081.20251126171621.ref@yahoo.com> <458400081.20251126171621@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.24794 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dHC1H52ncz43Nb Thursday, November 27, 2025, 7:58:21 AM, you wrote: > On Wed, Nov 26, 2025 at 7:16 AM Anthony Pankov > wrote: >> >> Recently I'm again facing a situation where some UFS (?) error on one >> partition forced me to reboot whole server and interrupt people's work. >> As I understand the brief is: >> >> Reason: A process in state 'D' (uninterruptible wait/sleep) is blocked on >> an I/O operation (e.g., waiting for a network file share, a disk operation, >> or a device that is no longer responding) at the kernel level. The process >> is not awaken to handle signals until the condition it is waiting for is >> resolved. >> Solution: You cannot kill a 'D' state process with any signal, including >> SIGKILL (kill -9). The condition must be resolved (e.g., fixing the network >> connection, waiting for the I/O to time out, or potentially unmounting the >> filesystem with umount -f if it's a mounted network share). In some rare >> cases involving buggy kernel code or hardware failure, a reboot may be the >> only option. >> >> In my case there was a jailed samba which share one ufs-formatted >> partition. The samba processes hangs one by one and sharing has stopped it >> work. >> There was no message in log. Geom reported no errors. Disk's has no error. >> It seems that there was some introduced inconsistency in UFS. >> My thoughts was to stop/kill samba, remove samba's jail, unmount partition >> and do fsck. >> >> But 'jail -r' exit with something 'rc.shutdown exited ... 9' and left jail >> running. pskill -KILL for samba processes say nothing and do nothing. >> 'umount -f' say 'Device is busy'. Various utilities such as 'df' hangs. So >> I forced to shutdown the server which has other important and workable >> service to resolve the situation. >> >> I wander is there any way to treat such a cases? May be 'umount -f' can >> have more power... >> > So no errors from geom? Or from CAM? what's the underlying storage > hardware? And what's the wchan / straceback for the processes in 'D' state? > And do you know the location of the file that's waiting for I/O? No errors. UFS was on gmirror and 'gmirror status' said 'OK'. Unfortunately I was unable to do meaningful investigation under stress. There was a number of smbd process in a jail which ignore killing and anything else. The first inconsistency found by fsck later was a file with mtime corresponding to a first claim of a problem from one user. Hour later there was more claims and finally samba share stop working. As I understand UFS inconsistency grew over that hour. Because there was multiple smbd processes each corresponding to different user there it is no one file maked problem. > There's a number of things that might cause this, but they typically are > noisy about it. There's a couple of deadlock issues that might cause this, > but getting some more information is needed to understand what might be > done to mitigate or prevent the deadlocks. > P.S. Previous situation was when I do simple (as I think) experiments with >> ggated and have forced to reboot server when 'mount' hung. >> > I assume ggate isn't involved when this happens now, right? That's right. I note this because it seems that stoping ggate server while running ggate client is the simplest way to reproduce the problem. P.S. I was really hope that "umount -f" awake waiting processes for killing. >> -- >> Best regards, >> Anthony Pankov mailto:anthony.pankov@yahoo.com >> >> >> -- Best regards, Anthony From nobody Thu Nov 27 12:53:08 2025 X-Original-To: freebsd-hackers@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 4dHGYy3Zt2z6JLKw for ; Thu, 27 Nov 2025 12:53:10 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dHGYy30p0z3PKh; Thu, 27 Nov 2025 12:53:10 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764247990; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2PdcMO01Zw0Xq5IyPuusOYnzmmE/TdZxrJPrVH3TjSg=; b=vO5PZrZx7vIaZFTJJz9oOxFy37fbVpgF/XC9A652sBqQ3WRuY1rcZYA9gGCPo8kaLElkH0 2PBJ/03Kp2Bvj1/3v3ytCq0BTKCprPtkCypTi7tBNcfs4+G0bFY849wtyvtsnb8n4VN1c+ JMiu0PUzPGIucWk++acqlhG632y1SsdxkWKJ6YTyZdF18Qwb3xFyarNoE/Y/wWP9F9TgEZ fjlazONtHSGw/7NwjaDI9awAlwuSdiwwdYeAFADq3onqFIcRdpj1boGW2/kEQyhCoXL12z ijL70ekIdNcPrPk3NR3sC9K+ET3/dFIUp5cfGuBNCOg8o13DxYb1Mn+aoO6+EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764247990; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2PdcMO01Zw0Xq5IyPuusOYnzmmE/TdZxrJPrVH3TjSg=; b=yDcUM52EsJLwMBDjp3greNwSVNBvVes8b9QFOhRp7XsARaLlIT2YRVQ21bRvyo+rhPsSQa xJzkebHcg31K6P03H8kvX6cTEc//6yM3ckiSjclh4emNyGXQnE1JXBzaR8/yRnpbNanoiW z5sZaRnvwfiUT1KxJ3v4LITcBHNtId9FfIMy7l+rMgHIls63ta7cj31f3ogIM0yYCFOEUw /OmjgWeyPWU5Utp1opuYW51pJCQKjhOwBaBYKIS/neZrq1Q7uLwMy8G1TkgeaDBI94Xyfz /BwnLnnkQpJ+iy3T/Njaj7pRiEChcqd9qzCuQnH5KBLEzu5kyZn6WQuTusBcWQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764247990; a=rsa-sha256; cv=none; b=ib1Ae6wod/58h+mc/B++qP5i3mLcXvlsRvfYybnTt0eB6pfX5GTeOBVH+V8AjJMTlMZkPn Xg7Uk7xLTyciULC9ZEme1dyZE4efqe/jGkhmjB6IbGUgbDcEsc5thNoPoBjgTv36Xh3/P7 Xchs7lf8R1FM8e5dSZEC5h4nxeyEyp4iw1fLB0uN+V0UsAUYur/q+TtH2UnMfp5Nwok8L4 3jlX7vXNuNcGhPShPci2J2Y4waCxuidDDgYXUmxq5R00QZJdpcfuwgJ4NP95kYDj8tEww6 ckcV2K5yOtJzxr2/Sp32DdiVDEeZr9Mo0ZUnVNWNYXMto2qplWn/1N7MI67LvA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (2a01cb0585090500922e16fffef1acef.ipv6.abo.wanadoo.fr [IPv6:2a01:cb05:8509:500:922e:16ff:fef1:acef]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dHGYy1c51z9xp; Thu, 27 Nov 2025 12:53:10 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id C06D68DD74; Thu, 27 Nov 2025 13:53:08 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: grembo@freebsd.org Cc: Tomoaki AOKI , Warner Losh , Mark Linimon , Sulev-Madis Silber , freebsd-hackers@freebsd.org Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) In-Reply-To: <20251126184515.4fe1ec7820f244deb428a2a9@dec.sakura.ne.jp> (Tomoaki AOKI's message of "Wed, 26 Nov 2025 18:45:15 +0900") References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> <86h5ui7qd5.fsf@ltc.des.dev> <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> <774F9B09-B506-4F8E-B293-CE705F64B77A@ketas.si.pri.ee> <1497323956.336174.1764124966236@privateemail.com> <20251126184515.4fe1ec7820f244deb428a2a9@dec.sakura.ne.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Thu, 27 Nov 2025 13:53:08 +0100 Message-ID: <86bjknk56z.fsf@ltc.des.dev> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tomoaki AOKI writes: > It would be nice if arcanist does NOT conflict with archivers/arc > (/usr/local/bin/arc conflicts). If it was, I could have been gone > the way git-arc. Michael, could you please modify the arcanist ports so they install bin/arcanist instead of bin/arc, and only create bin/arc as a soft or hard link if an option is provided? Then we can modify git-arc to use arcanist instead of arc so it works with or without the link, and people who have this issue can simply install arcanist without the link. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Thu Nov 27 12:58:59 2025 X-Original-To: freebsd-hackers@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 4dHGhj2s04z6JM2K for ; Thu, 27 Nov 2025 12:59:01 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dHGhj2N62z3RS4; Thu, 27 Nov 2025 12:59:01 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764248341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jrFbwmn7ZJfuWBwkbls+wHnLnMLCTZ9XfRN0qwHupZ0=; b=C2OfBtPUP0PEeoS42FCmYqIX17LzJBXBtrXxyY7mUu1ny9Kb/ejQBEb0k6/XfThN+MYlwd VEJOyYQ5GoEHdNKIY7x9uTzjGVAhJwGcCwN7fK3e82GVz3mMiU0N9exKocNMarulMwKXBP W6U4e49hjy5OQz7scPYR9QaDYaMXfkHp11hu6rfA1bOVRmhLp+E+TGfA+6zD1AXMjDZygd I/HrMNhPD8VTGZUITBqsvvUnk7HYZsyriyp58GI5/6BUOpDkMBDxxQLebaY96+Kftf4IGG fkNEUwzR/uohyA+pl8HTwl3U0f6blO/kYTzqjCdXDCNWJAjFXYGBSVCBMErmAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764248341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jrFbwmn7ZJfuWBwkbls+wHnLnMLCTZ9XfRN0qwHupZ0=; b=m8WNAypxdQjEPYseEBi6CCXNBjB+F4LVmt2viI6/BHQSmi+XMpYEUe+qEy0UjAvHWU7iec GGodZFq46ZsaiIBWKiciViMVouEuLqqfyaj0RZpH7pwjpalsWn65ealYpOT/A9zCcL8HcD IM6M5zt0qCgiRRRsYdkMRWgVUE9aIiiYNIdgTK1PbheeqNq61SreRfRo97pP3cn3Uk6E72 Ts16D0jdrVuIQWgA9osC/NsWcsR6s+gHJ4amwQ0VXiTaPEjzK1iDI1hLTtDHk4ZUPTmGjw RWoriEKyTir0jIEzzSOGANvD4EvsSb50VPwwpvJGRtweAjI9SYE3CI1Tubatpg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764248341; a=rsa-sha256; cv=none; b=RBgzKm0JEkmGRPCDJ8XroFRv3qAgysIHmNMN7BeMbpr1nMuNAyFM52GhwX7o4sK9FhlhNo py4bQPMiks74FV+tWW1IxQLjikRkzH/zQKnkLhUgeRse9RzJl+jQ4luDePxNDKOywr5tMx wDzQ2zPQbkJxWPUXzQQDAde8al6QSK4NV0qTBlBuGihV1TMVZ9yYdppSIinqaZBodNWt6X BjRIjLzgxdffzio5OweLWVPIQeRMHMXfXViuIeEwEqp5i223Yw85mYZDNIVPJLy7w92Q2I IelDFH510EfNf7atjdZjJ57KdF5iEm3WKvH7B6XA25EBLSf/NhTrgcwmhc+hWw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (2a01cb0585090500922e16fffef1acef.ipv6.abo.wanadoo.fr [IPv6:2a01:cb05:8509:500:922e:16ff:fef1:acef]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dHGhj11NwzBxX; Thu, 27 Nov 2025 12:59:01 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id A5DB58B9EB; Thu, 27 Nov 2025 13:58:59 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Sulev-Madis Silber Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) In-Reply-To: <6B77F3D4-C55D-4C63-9537-EBC151AFA35F@ketas.si.pri.ee> (Sulev-Madis Silber's message of "Wed, 26 Nov 2025 11:48:43 +0200") References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> <86h5ui7qd5.fsf@ltc.des.dev> <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> <774F9B09-B506-4F8E-B293-CE705F64B77A@ketas.si.pri.ee> <1497323956.336174.1764124966236@privateemail.com> <6B77F3D4-C55D-4C63-9537-EBC151AFA35F@ketas.si.pri.ee> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Thu, 27 Nov 2025 13:58:59 +0100 Message-ID: <867bvbk4x8.fsf@ltc.des.dev> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sulev-Madis Silber writes: > nobody wants to change their repo locally just to get diff out of it, Wrong. This is exactly what Git is for and what sets it apart from most of the competition. Just commit your change locally (preferably, but not necessarily, on a new branch) and learn how rebase works. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Thu Nov 27 13:21:58 2025 X-Original-To: freebsd-hackers@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 4dHHCJ3Cr3z6JQB4 for ; Thu, 27 Nov 2025 13:22:04 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dHHCJ0Y9Mz3XB8; Thu, 27 Nov 2025 13:22:04 +0000 (UTC) (envelope-from grembo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764249724; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eWWMzEq4cTHWbzj3mx/SuaIJ2htPyPNhphwyrNWG0KE=; b=fikO313G1l37udttK1hokeLgV5BIh2zQM2Al1u/PobWgzR3cHY+xtE3nPVizPWFmhaASOC w6xEexIqBjuZzZapMtLprwQY9X7eQ+cYAP4U1OQB+dlZQCakGTV5/Xlgd6A6TPrmiHyeWI gsjNCvvy12RT/yUf014FS0+Fh6PZQxf7i80D+SzQO+M93C2jKNtEayrdJIsVl4ZZMqSO/D JjnF6n/aTQg//ERzID9cis6QKyPFn2E3QXwn4csKyykDb9WFpLK9+xvr8shPhUkndwvMOX PPzC+xOHAnfDnBcC9oB+hLmU3t7QPLf6Yj+mc3g5YCrWMb+R7wFaZgEbQYABaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764249724; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eWWMzEq4cTHWbzj3mx/SuaIJ2htPyPNhphwyrNWG0KE=; b=fhC4VoO+PiMCqNPO836VbcmMl2gCmi2IRcoalMOPMY87kNgC5IOoK1v+E4Hbx4k/mj1PNx g/+kamqGT4J3TrkNWtq1O8aEEAZgO/lYqKxeg7+ZzalAjSYhM0rQY6grz2shBvW8gMc05D dV8Aj6bafjNe48QHUEbPms5dVc32N/kH9CgAwXhk1ujJ3v2LbiTdT1OjoXE3lJAjwe/xmy OkNAHiW4WX4zzqyucbDlgny3ST4nAoqYEZTGXi/8/QGorNscgpR/7IjH6MNnU0vZbROh+M VXngzzDWBRCQT0m74sRMGPNjB5LP4zFU94e/RIewm/+Qrv6PAiZRDkr3lpYjIw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764249724; a=rsa-sha256; cv=none; b=LBRMUp/MKb8e9ZLNSaGQm0Hy4C8qvCvGla6NRVC/rr5bsWPFz/fPtc09d8WNd21KJHnaRo 2/wLRMjL1lsIc3QVbESWxQg8FRzyk13CGYs1XeY5zgh9+cXx0KlmsxizDbqhKV9xOQm3xp PGIv5llCtOoiGC0DywDy8E1Rcr/jUEL0J8Oxn0GYE+gKEIECXW2kHtey8IzqwH1Lmire/R ikNo2ib5z7bdEpWNExpPQ9zcB+unshBKRFejDs4D2Jd54RzxZytVVnYPnvUHqxtsJdcJrN BLgICXDooB7aWKL3X/LQDogAvOosB2VwdyuSM7Apsdj45J6FnZcC5YllDrQuPg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) (Authenticated sender: grembo/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dHHCH1mk9zCrq; Thu, 27 Nov 2025 13:22:03 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 6dc99d42 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 27 Nov 2025 13:22:01 +0000 (UTC) Date: Thu, 27 Nov 2025 14:21:58 +0100 From: Michael Gmelin To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= Cc: grembo@freebsd.org, Tomoaki AOKI , Warner Losh , Mark Linimon , Sulev-Madis Silber , freebsd-hackers@freebsd.org Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) Message-ID: <20251127142158.68f5e126.grembo@freebsd.org> In-Reply-To: <86bjknk56z.fsf@ltc.des.dev> References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> <86h5ui7qd5.fsf@ltc.des.dev> <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> <774F9B09-B506-4F8E-B293-CE705F64B77A@ketas.si.pri.ee> <1497323956.336174.1764124966236@privateemail.com> <20251126184515.4fe1ec7820f244deb428a2a9@dec.sakura.ne.jp> <86bjknk56z.fsf@ltc.des.dev> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 27 Nov 2025 13:53:08 +0100 Dag-Erling Sm=C3=B8rgrav wrote: > Tomoaki AOKI writes: > > It would be nice if arcanist does NOT conflict with archivers/arc > > (/usr/local/bin/arc conflicts). If it was, I could have been gone > > the way git-arc. =20 >=20 > Michael, could you please modify the arcanist ports so they install > bin/arcanist instead of bin/arc, and only create bin/arc as a soft or > hard link if an option is provided? Then we can modify git-arc to use > arcanist instead of arc so it works with or without the link, and > people who have this issue can simply install arcanist without the > link. >=20 Hi, All the arcanist port does install the symlink: arc -> ../lib/php/arcanist/bin/arc If you don't want that, install only arcanist-lib pkg install arcanist-lib and call /usr/local/lib/php/arcanist/bin/arc directly, or make it a symlink to something else you prefer. Best Michael --=20 Michael Gmelin From nobody Thu Nov 27 13:52:21 2025 X-Original-To: freebsd-hackers@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 4dHHtJ4T3Mz6JShw for ; Thu, 27 Nov 2025 13:52:24 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dHHtH5HFKz3bDD; Thu, 27 Nov 2025 13:52:23 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764251543; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NuvVzJ/NM0FsbtPOzYTg6FuZwOK2j3Qf3EJJMn69Yac=; b=u/4FZBoOK8UUmdgcc8bQJFGLc3TR0NibWV/yrC+O+RpClPtUga+kWHRTjDvrIdA2aaWYA/ LbGSUQW8TNbIL7z7hB9h9GxjY5/9D/VBchTLFPK0qwifD/uHsCTJY1vylzlsX+l6ysi5za 1ZvazbqFs2ns/hezIo/RuM3AMa6Z1CS34ADjWG8z5I0jAPLNt8DoyJJzUdBPeUfMRF0jVf jKPhQRS+JGIkseNIjmVj0A9Pn5VKmlxEDH7lXjFY07ToYY1xlPHJ8o8Ibu7dXyGITvNdx3 XieWmPVsb9H56Rv8KWWTkihZPZUSIyGvehnWJPgxw4dufCsqPnW95cSnKmqiyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764251543; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NuvVzJ/NM0FsbtPOzYTg6FuZwOK2j3Qf3EJJMn69Yac=; b=XH50HkDHDXdZvHfRVhSFrOyxPw7mDL5iyx9P72yG9vwiRGb7qmKoRDgWRDR9sBqNuwo3wd aX15jEu2U7Q91PhnM3J3lZc0CtCAO8zrwnGQEI5Cl3MDFpxZ0BdGLiQnosWXTOYx4ckXRB +12ziL3PABoczCWnQ1ZcSUZ0PvNB/QwV9nFkXsWUK08IxNCG1JOPqe+UkFsqjAZp3k+N8d ThlBbOo3x3BOKl7HdkOB119VPHpLzymC71bcgeJc7lCNGt9byQ1mZBm+gmvhNpDhJwptfo QTPBybnZV7ekUOP0Kx4N8zJPxOHoC6i1THAvPTdbxluPNTTga4soJ/q7Y4yvfg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764251543; a=rsa-sha256; cv=none; b=mZ57XcB4mHmZCJTvh6wkeE5RKs6Zx3FGlyRNbTGS6HsWqRoEhBz6++U7GD6vR+NR2us6IL Pca7nAxR73FSmO09/d0nDkvmZN2CxwDF+VC4/ANEg/I/84wKD/NDv0CJ+RpCrhxd/cfywe G8FyIwUXV4SGK0SmBXLeG22BJSEQ6ZLYoY62lm5Yz8M56TNpkD+1tDVPR4T122Nfx6eUT9 ROIaP2t/7NEd/O6bAt+2qrRiLWE4QScHYo6pwZnYP1qzrT+3ju5Uo3r1aTIeNb9GUiXqSK FSrTLzRwQ7sIGurhmQQGpUB/hQ4ziyS1sKFrgI5YHNZf5FniL0lC00wP9ObSIw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (lfbn-nan-1-698-103.w86-236.abo.wanadoo.fr [86.236.35.103]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dHHtH47kxzDK4; Thu, 27 Nov 2025 13:52:23 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id A07128DEB9; Thu, 27 Nov 2025 14:52:21 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Michael Gmelin , markj@freebsd.org Cc: Tomoaki AOKI , Warner Losh , Mark Linimon , Sulev-Madis Silber , freebsd-hackers@freebsd.org Subject: Re: [PATCH] df: correct BLOCKSIZE handling for -k to use 1K-blocks (290710) In-Reply-To: <20251127142158.68f5e126.grembo@freebsd.org> (Michael Gmelin's message of "Thu, 27 Nov 2025 14:21:58 +0100") References: <1789299192.176069.1764023439861@privateemail.com> <20251125082605.0cb9ab55a2c71a415b575c41@dec.sakura.ne.jp> <86h5ui7qd5.fsf@ltc.des.dev> <20251125214658.eb1e0cdf9df97601b9e28de9@dec.sakura.ne.jp> <774F9B09-B506-4F8E-B293-CE705F64B77A@ketas.si.pri.ee> <1497323956.336174.1764124966236@privateemail.com> <20251126184515.4fe1ec7820f244deb428a2a9@dec.sakura.ne.jp> <86bjknk56z.fsf@ltc.des.dev> <20251127142158.68f5e126.grembo@freebsd.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Thu, 27 Nov 2025 14:52:21 +0100 Message-ID: <86345zk2ga.fsf@ltc.des.dev> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Gmelin writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Michael, could you please modify the arcanist ports so they install > > bin/arcanist instead of bin/arc, and only create bin/arc as a soft or > > hard link if an option is provided? Then we can modify git-arc to use > > arcanist instead of arc so it works with or without the link, and > > people who have this issue can simply install arcanist without the > > link. > All the arcanist port does install the symlink: > > arc -> ../lib/php/arcanist/bin/arc > > If you don't want that, install only arcanist-lib > > pkg install arcanist-lib > > and call /usr/local/lib/php/arcanist/bin/arc directly, or > make it a symlink to something else you prefer. So we just need to adjust git-arc to use the actual script instead of the link, and the freebsd-git-devtools port to depend on arcanist-lib instead of arcanist. See . BTW, you don't actually need to install the port to use git-arc; you can just `ln -s /usr/src/tools/tools/git/git-arc.sh /usr/local/bin/git-arc`. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Thu Nov 27 22:06:19 2025 X-Original-To: freebsd-hackers@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 4dHVrY5tgPz6JFG2 for ; Thu, 27 Nov 2025 22:06:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 4dHVrY3Vmgz3gRc for ; Thu, 27 Nov 2025 22:06:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-343ff854297so1577463a91.1 for ; Thu, 27 Nov 2025 14:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1764281191; x=1764885991; 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=/uzuOmdnX9E5R7tCVF28w3VWaH66MwYOSeKJCuQr0Jw=; b=zpVYVvKYTP7CxWwjbc44KkWhoh/LdFS+HrPBP2oZIIPzRRpgwsnGWmCstsYfnySAgl q3OpYETRM4I7LYVpy6Yl6hTdxfIQ5F+zLQtY57lBtdLLitLuEZzDyag2/HVa+5ziQO7S 8aeM6xacZF/pi7o5pO86YhgonxsL6vRa+8nVR7UEyS72uqBJgASlcEDszr+6jQQjOqf4 DApHGHhrlhO4LQ+i/WP743eahJVDH758h72xlh8y0b1IqzCChypprgt+jK6p0XfgdMZZ c4EJTAUB1xKvbnincv8kWPSyIYhUnhNcSg4mPNBhHFU3OFi6wx929hPm5maV3E2WtGEX 5S/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764281191; x=1764885991; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/uzuOmdnX9E5R7tCVF28w3VWaH66MwYOSeKJCuQr0Jw=; b=Q6La1Av86NSu95DdgeMqbtU4O4uq4T3E4amFXNssC9CjKf4G4NAInqd9DCxEYrFMwi nQKrc1wCFca4O9+5lf5dipJTeLqYobaGVL7qgDOAM9vK7J3a+/E6sFCzc1+HXLEPcKmW xiRD5fn2vmh4LcF7PsshvxNox4HTlNbbIr3ZICFrUe2QIfE2BAOoDsILivfMgEXXExrD djCVmEefWjqkLEAGfRydHQH+kwtgUyAqGZQKrI7sSlaFgVNDP+55NVJHD8zfpeNl3KZ0 BtuQI72ZnzNQ2JFibDzq31ObqMhKpjUvimEbSXbLY4QYqp+ZD4sP/eMuT1gAClf/XeVa VPRQ== X-Gm-Message-State: AOJu0YzuobYL1JWbxvaGPQpAweQ3rbtPTI0AhOqfaLoVQxEfz4uh4mMG xRNgMLVPeSm+vb+Woa7Djrsh19a6AZEsORObnM3YbKO8rNS7R22SEBknD7DO+lgdzizyYTCl9o6 iR60x8ifxmWjhdlK3GwtTkmW65kSD+uEUzzOkxF2LMw== X-Gm-Gg: ASbGncsrhrjKTjx3F2bYI1VG7dtMKZC+EJ7h6NUB+fQvaQ5T3DQeN7wGlKFKeWfVo8t hkqwxR3Yn3ZoOLiuSo6YtiGidDcROuL1DKeDmdn4ZnNtVhSw2roW++XgJobXArM8SevKqR07S2K kHIPICZooGa3pl9mIpG4oNz289+o7M460UCZo7PbGujTM2mbtcR3G99MXbEdEoBZpr4yb6BGdWC vxD27n/WcxoWOH+biHc8p2he5gO3ypV+WQmXfezKbsggdrwc1NaciSgMau/QItxKTaHZ1O16UbC mz39Og== X-Google-Smtp-Source: AGHT+IHJkWm/y8/QjmsUXLpuqRDJn90WTg7cqaISMbcFgs0XFfRgF1JEq8O9NwhuE6ep4FHM1QdR/69uWrDNkW92Ubs= X-Received: by 2002:a17:90b:4b8c:b0:340:c4dc:4b70 with SMTP id 98e67ed59e1d1-34733e4ce95mr24902466a91.6.1764281191082; Thu, 27 Nov 2025 14:06:31 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <458400081.20251126171621.ref@yahoo.com> <458400081.20251126171621@yahoo.com> <908785764.20251127131317@yahoo.com> In-Reply-To: <908785764.20251127131317@yahoo.com> From: Warner Losh Date: Thu, 27 Nov 2025 15:06:19 -0700 X-Gm-Features: AWmQ_bnPQHgHI6paWpAmuKGfjqAy8XgLRBRVSethDYVgPoFVpYeToU_0AETWYGo Message-ID: Subject: Re: any way to recover from I/O hang? To: Anthony Pankov Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000adbb8006449ab978" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dHVrY3Vmgz3gRc --000000000000adbb8006449ab978 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Without a wchan waiter or tracebacks, I can't help at all. Nothing you've said is actionable, alas. umount should clear everything up, but if you've hit some bug where the I/O never completes due to deadlock, nothing can help you... except maybe tracebacks to we can understand what that deadlock might be. Warner On Thu, Nov 27, 2025 at 3:13=E2=80=AFAM Anthony Pankov wrote: > > Thursday, November 27, 2025, 7:58:21 AM, you wrote: > > > On Wed, Nov 26, 2025 at 7:16=E2=80=AFAM Anthony Pankov > > > wrote: > > >> > >> Recently I'm again facing a situation where some UFS (?) error on one > >> partition forced me to reboot whole server and interrupt people's work= . > >> As I understand the brief is: > >> > >> Reason: A process in state 'D' (uninterruptible wait/sleep) is blocked > on > >> an I/O operation (e.g., waiting for a network file share, a disk > operation, > >> or a device that is no longer responding) at the kernel level. The > process > >> is not awaken to handle signals until the condition it is waiting for = is > >> resolved. > >> Solution: You cannot kill a 'D' state process with any signal, includi= ng > >> SIGKILL (kill -9). The condition must be resolved (e.g., fixing the > network > >> connection, waiting for the I/O to time out, or potentially unmounting > the > >> filesystem with umount -f if it's a mounted network share). In some ra= re > >> cases involving buggy kernel code or hardware failure, a reboot may be > the > >> only option. > >> > >> In my case there was a jailed samba which share one ufs-formatted > >> partition. The samba processes hangs one by one and sharing has stoppe= d > it > >> work. > >> There was no message in log. Geom reported no errors. Disk's has no > error. > >> It seems that there was some introduced inconsistency in UFS. > >> My thoughts was to stop/kill samba, remove samba's jail, unmount > partition > >> and do fsck. > >> > >> But 'jail -r' exit with something 'rc.shutdown exited ... 9' and left > jail > >> running. pskill -KILL for samba processes say nothing and do nothing. > >> 'umount -f' say 'Device is busy'. Various utilities such as 'df' hangs= . > So > >> I forced to shutdown the server which has other important and workable > >> service to resolve the situation. > >> > >> I wander is there any way to treat such a cases? May be 'umount -f' ca= n > >> have more power... > >> > > > So no errors from geom? Or from CAM? what's the underlying storage > > hardware? And what's the wchan / straceback for the processes in 'D' > state? > > And do you know the location of the file that's waiting for I/O? > > No errors. UFS was on gmirror and 'gmirror status' said 'OK'. > Unfortunately I was unable to do meaningful investigation under stress. > There was a number of smbd process in a jail which ignore killing and > anything else. > The first inconsistency found by fsck later was a file with mtime > corresponding to a first claim of a problem from one user. Hour later the= re > was more claims and finally samba share stop working. As I understand UF= S > inconsistency grew over that hour. Because there was multiple smbd > processes each corresponding to different user there it is no one file > maked problem. > > > > There's a number of things that might cause this, but they typically ar= e > > noisy about it. There's a couple of deadlock issues that might cause > this, > > but getting some more information is needed to understand what might be > > done to mitigate or prevent the deadlocks. > > > P.S. Previous situation was when I do simple (as I think) experiments > with > >> ggated and have forced to reboot server when 'mount' hung. > >> > > > I assume ggate isn't involved when this happens now, right? > > That's right. I note this because it seems that stoping ggate server > while running ggate client is the simplest way to reproduce the problem. > > P.S. I was really hope that "umount -f" awake waiting processes for > killing. > > > > > >> -- > >> Best regards, > >> Anthony Pankov mailto:anthony.pankov@yahoo.co= m > >> > >> > >> > > > -- > Best regards, > Anthony > > --000000000000adbb8006449ab978 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Without a wchan waiter or tracebacks, I can't help at = all. Nothing you've said is actionable, alas. umount should clear every= thing up, but if you've hit some bug where the I/O never completes due = to deadlock, nothing can help you... except maybe tracebacks to we can unde= rstand what that deadlock might be.

Warner

On Thu, Nov 27, 2025 at 3:13=E2=80=AFAM Anthony Pa= nkov <anthony.pankov@yahoo.c= om> wrote:
anthony.pankov@yahoo.com= >
> wrote:

>>
>> Recently I'm again facing a situation where some UFS (?) error= on one
>> partition forced me to reboot whole server and interrupt people= 9;s work.
>> As I understand the brief is:
>>
>> Reason: A process in state 'D' (uninterruptible wait/sleep= ) is blocked on
>> an I/O operation (e.g., waiting for a network file share, a disk o= peration,
>> or a device that is no longer responding) at the kernel level. The= process
>> is not awaken to handle signals until the condition it is waiting = for is
>> resolved.
>> Solution: You cannot kill a 'D' state process with any sig= nal, including
>> SIGKILL (kill -9). The condition must be resolved (e.g., fixing th= e network
>> connection, waiting for the I/O to time out, or potentially unmoun= ting the
>> filesystem with umount -f if it's a mounted network share). In= some rare
>> cases involving buggy kernel code or hardware failure, a reboot ma= y be the
>> only option.
>>
>> In my case there was a jailed samba which share one ufs-formatted<= br> >> partition. The samba processes hangs one by one and sharing has st= opped it
>> work.
>> There was no message in log. Geom reported no errors. Disk's h= as no error.
>> It seems that there was some introduced inconsistency in UFS.
>> My thoughts was to stop/kill samba, remove samba's jail, unmou= nt partition
>> and do fsck.
>>
>> But 'jail -r' exit with something 'rc.shutdown exited = ... 9' and left jail
>> running. pskill -KILL for samba processes say nothing and do nothi= ng.
>> 'umount -f' say 'Device is busy'. Various utilitie= s such as 'df' hangs. So
>> I forced to shutdown the server which has other important and work= able
>> service to resolve the situation.
>>
>> I wander is there any way to treat such a cases? May be 'umoun= t -f' can
>> have more power...
>>

> So no errors from geom? Or from CAM? what's the underlying storage=
> hardware? And what's the wchan / straceback for the processes in &= #39;D' state?
> And do you know the location of the file that's waiting for I/O?
No errors. UFS was on gmirror and 'gmirror status' said 'OK'= ;. Unfortunately I was unable to do meaningful investigation under stress.= =C2=A0 There was a number of smbd process in a jail which ignore killing an= d anything else.
The first inconsistency found by fsck later was=C2=A0 a file with mtime cor= responding to a first claim of a problem from one user. Hour later there wa= s more claims and finally samba share stop working.=C2=A0 As I understand U= FS inconsistency grew over that hour. Because there was multiple smbd proce= sses each corresponding to different user there it is no one file maked pro= blem.


> There's a number of things that might cause this, but they typical= ly are
> noisy about it. There's a couple of deadlock issues that might cau= se this,
> but getting some more information is needed to understand what might b= e
> done to mitigate or prevent the deadlocks.

> P.S. Previous situation was when I do simple (as I think) experiments = with
>> ggated and have forced to reboot server when 'mount' hung.=
>>

> I assume ggate isn't involved when this happens now, right?

That's right.=C2=A0 I note this because it seems that stoping ggate ser= ver while running ggate client is the simplest way to reproduce the problem= .

P.S. I was really hope that "umount -f" awake waiting processes f= or killing.




>> --
>> Best regards,
>>=C2=A0 Anthony Pankov=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mailto:anthony.pankov@yahoo.com
>>
>>
>>


--
Best regards,
Anthony

--000000000000adbb8006449ab978-- From nobody Fri Nov 28 09:48:44 2025 X-Original-To: freebsd-hackers@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 4dHpQT4cyBz6JY5J for ; Fri, 28 Nov 2025 09:48:33 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Received: from sonic310-57.consmr.mail.ir2.yahoo.com (sonic310-57.consmr.mail.ir2.yahoo.com [77.238.177.30]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dHpQT1ZM8z46v4 for ; Fri, 28 Nov 2025 09:48:33 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1764323310; bh=bg6e1ToHXr0S5yTiPriClrvrbsMHtmqZQcu6ZsHgciA=; h=Date:From:To:CC:Subject:In-Reply-To:References:From:Subject:Reply-To; b=cLBqKr4XERiMqtBHmP2gMAQl0Xr3Sgb0vhGxKJEOB2GCRLcmdJgnt4AB3juDYSeyoyZmMvWB2Oseri4tcfjckT9siZyDkzK74yt4iGWMuKZ9mY8eT4tv0n+fxe4hUIxLRFj/IKz/aGEDMkzUdLr0w2vlK25+oavEaNnBrB9vV3rmPf8ET/C1ptcAJD5cnjmLSxJTiAzmpdZQRfSW6FIE+VCJu2BhWBUT9EMzE8zSONdoR6vLy4aUVWK5REIMS/b0xX310Jt3mORDw/xGmPq7hYfR5wHDgEM4ZNgb89/0I4KVdCuxNcrjIqpn026eQozh1sB5zsz1irEjmX9ZBWlcmw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1764323310; bh=fAjeVUjLCwusautHccPSC5XMV7G0Bcbyg+8q/f7163y=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=rBPqYxqWe1uxUbMHmnZoZnOTPWHl1DxPXVjOfOaSFbOad2/TJZqaSfYI7q47tMx5r7r9r1uD/RaBP4Mr0/Y+Gt/XllNiOqA22rMWJX/MJSbbBRmKUJAVx0tTYS95OxQHizPpGbgMI8t79Bdce1LnoAq/Fk4J/qyOpBro+QZMU3I3PYXXvusR2vhLa0WnL+E0EPOunyKdGs58zaNW1jSWBg1yVyzgyXCA0+pmb/PpCIk4SBsiuzhVyT3LoYnQJ69QXzg4nN5dipu+T9LWWODUqTCgxu5nqOYR90zxykbxCfkOIXp3uFmGU2B+/RxUhzoJb+iKM8M7ejvwKrw64/wqiA== X-YMail-OSG: nCrGcWEVM1mcIGhjJfMND.xUtPlI..Lox.yefbjpvtVZKVsc2G6EMnaAotbkEQK YD97j4vszNRRcDjHAUxqqBSY30kX6w.O9EU5vq9OoZnsX_LnCYf3YFAMrG4D_5HnzWp9a04Eo.EA r1LkcoJWtBY4Opm6_Ab4UQl7PdRncE.dxkXBnVHRCBGe_fwsTiI27U8IBAKTlyJtGS5DXMLOK0Sl y6tXYgNpApIr60FbjNRiZgT_dAKuWGo6VAFyNPRiL_4wquD3rsK_TzIWz2_qH6pklcvuzVzQihvZ Xvc9N5CTvUMzcQRVoRo_i15_0MbAvpgmaMrNeyuhOD8ZxaACtn0_.QHKftvyXj4mRylNTngxUlmw 7RwNQxtOqARSIUDAIKipm4hI4hfSasWwH.kgupRUBf7rl5_7p74hsqOjgNVeYbPdkhvC.vyjxwWe V0JfdqxCdf8RTicvO6lGOzvcFVo2lj7rGFGhltmKsq33AOrM6mUjRvjY3z1jyt8pYWh2UyNm895_ w_vZYPqVXN6maZpRA0DolcmTHkgp.BEXPrDUKkhOPSb2E0O4lo9SCwGgJj0pDbZCvSQNviM83DJd 8FvVM66m5xYWaxzgUnL9GV43QhL6u1n1.mBFD9gn6299OMHtVvP1Md9So3KjVprrU5JaKf.WF5E1 ra4mIX7dTXJRXZXspexTIyFG3swx1KHNBkIdmgr1OqBI.wkwr2qKjKWacnBfdnzizAl9ED_Nwp_q l_igBFlXgBlCS7hSSOKbbi9yoAZteSXb52Z8Nrz2WvPzUxV1wVBdf.eiJZKLs_dyC6OjKyFHKZrk e.ju.Kk9Lw0D.AWQnOyX.ur_PjEM1sGaLJJKv26X.mVWgN1LBS0m.IwrRD4.RurSSovHXTrZsL64 ugAHL2uMWcH1dRthLxVHqhgyc73KQTRfTr9CJk.Pxksbz4_2kB6TZNig4HSj0OBWrDCaxb3PWrtx SUomUGFRp_Jj2v8I2J.ZLJ3cUoGJ2qP1Bc_0VWAwhXx1jPTG5SJ457NmJqk3CcMxI8R2OKzMyL83 A3lFex3iSadpcJp71HsR7GPyju4Gb52QsmfMWkopAqpNRonszyIpT06J3v.GOyrn.iKOEpQAswgA ObBO6hnXL_ftL2gDUIUCNmIal8WYLc7BSkLKpOE0SRryOrag_F45jhe0ii63H47F.LSIXtSC8h20 NrH2t1108TpyFcfNvzVJBF.2_YMg6a7q6uRsn.khXVvlgduQz35CVxwN74FeyOuINTQkIEe3nw0c yyoQcdfbn.9ragqB4PP8wuGeKZ7ktgOSOKHYCXY1IsKZomy4pwAwDgojrdPXRIgiX3Q.5PVYKzhX 9Hae0BKdkcAI3_GL8kZUjC2u8g0wUerU_JKzK964lSIoHPL0jg2ucSL3O8.u480R_kMV4FEOjVHk AZXaq1wPEwzWuWOJTB91le.aLnCTiX1MpmCdYnCRVnEQtX2OWfNiCl9LuueQfqvulWwHcyyhWcfK 8dZC37FrdePsG3IvSsHY8AcebTvOoSwI4ybj_nLULI4pc9Oci1ClO_ZHrUHpoQbvQN8Nr845EeF6 jEbnSc5mfAqy_B4yY0ticZyVjtYqVnLoHDM_itR1j9OLvUgyBMebNuQPAdOZe5Elnzj_BNGUeoNr oUU7iug2bhbYTYri6Z.4n1JK2wsLeo2JadV0sgtGJhnqruOOGu8eKnjr3ZQe9dMEzoQTZJjGThCU eZNHPNP6xkgJ2Xi4usiOlQWiYb2V0AZgMqAJ_8dJLod76Iby4DaMb9UEgBQakSJ_WfhVd.Oqfd5P keh4sqSr0NWUb6yrzrn.OSENuSz6dTlvEgoV9og305.ZA5uh0w2NRqM449m6GQD.YONgZgJZWdCe FEk7S1kxni5tpSut9yRao5J_qOyBbIBQ59qn5rHTMLj16lDEAamw.QwpB6do96YyfRzQB8nRFcLd e.cF_nz.5cjVfZNjxWsLcgsJEEH7kQuy3_bn12LcEiaS3VzfYVG.hy0thDD9Bb3NlLnnNM9DAAsE ZiY3bG9dVbupXPxthWE6Wide_JGELj1XbXqSM1jPfXVlog2FfINavTACpFbbRMrr7FiKi4kDRwbW e1X.t4FgHnk1AigPcFmkozMCInfNbapEZYKk.ZpN8rJGo6VzUe1QMWT1LvU7Lup9nPwMKN.dzm4j hSStxj9SBLKZKT5jc9vAMtBVCLXrf4yPjsTQlsFxWOXVmtYiGCE9hAMq_5W6TSxB_qDHg0ASLgp1 QpA0iDd5b1RGzsg.USWoZ0.3e2w-- X-Sonic-MF: X-Sonic-ID: 7f525482-883a-4ca2-931c-dcad45eaca1b Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ir2.yahoo.com with HTTP; Fri, 28 Nov 2025 09:48:30 +0000 Received: by hermes--production-ir2-76fb978d99-n5kt6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4262976befc841241317d34e0fb6a73d; Fri, 28 Nov 2025 09:48:26 +0000 (UTC) Date: Fri, 28 Nov 2025 12:48:44 +0300 From: Anthony Pankov Message-ID: <1777092313.20251128124844@yahoo.com> To: Warner Losh CC: freebsd-hackers@freebsd.org Subject: Re: any way to recover from I/O hang? In-Reply-To: References: <458400081.20251126171621.ref@yahoo.com> <458400081.20251126171621@yahoo.com> <908785764.20251127131317@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.24794 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34010, ipnet:77.238.176.0/22, country:GB] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dHpQT1ZM8z46v4 Friday, November 28, 2025, 1:06:19 AM, you wrote: > Without a wchan waiter or tracebacks, I can't help at all. Nothing you've > said is actionable, alas. umount should clear everything up, but if you've > hit some bug where the I/O never completes due to deadlock, nothing can > help you... except maybe tracebacks to we can understand what that deadlock > might be. I wander do kernel care about infinite I/O waiting? Neither the problem nor previous situation with ggate doesn't seem like a deadlock for me. If I remember correctly with ggate reviving ggate server do revive 'hanged' client which also was unresponsible to -KILL and 'umount -f'. Anyway I think it's very desirable that 'umount -f' will apply more force and not give up with "device busy" message. I partially understand that "more force" is a complex problem. May be of something like replacing mountpoint vnode structures by deadfs structures. > On Thu, Nov 27, 2025 at 3:13 AM Anthony Pankov > wrote: >> >> Thursday, November 27, 2025, 7:58:21 AM, you wrote: >> >> > On Wed, Nov 26, 2025 at 7:16 AM Anthony Pankov > > >> > wrote: >> >> >> >> >> Recently I'm again facing a situation where some UFS (?) error on one >> >> partition forced me to reboot whole server and interrupt people's work. >> >> As I understand the brief is: >> >> >> >> Reason: A process in state 'D' (uninterruptible wait/sleep) is blocked >> on >> >> an I/O operation (e.g., waiting for a network file share, a disk >> operation, >> >> or a device that is no longer responding) at the kernel level. The >> process >> >> is not awaken to handle signals until the condition it is waiting for is >> >> resolved. >> >> Solution: You cannot kill a 'D' state process with any signal, including >> >> SIGKILL (kill -9). The condition must be resolved (e.g., fixing the >> network >> >> connection, waiting for the I/O to time out, or potentially unmounting >> the >> >> filesystem with umount -f if it's a mounted network share). In some rare >> >> cases involving buggy kernel code or hardware failure, a reboot may be >> the >> >> only option. >> >> >> >> In my case there was a jailed samba which share one ufs-formatted >> >> partition. The samba processes hangs one by one and sharing has stopped >> it >> >> work. >> >> There was no message in log. Geom reported no errors. Disk's has no >> error. >> >> It seems that there was some introduced inconsistency in UFS. >> >> My thoughts was to stop/kill samba, remove samba's jail, unmount >> partition >> >> and do fsck. >> >> >> >> But 'jail -r' exit with something 'rc.shutdown exited ... 9' and left >> jail >> >> running. pskill -KILL for samba processes say nothing and do nothing. >> >> 'umount -f' say 'Device is busy'. Various utilities such as 'df' hangs. >> So >> >> I forced to shutdown the server which has other important and workable >> >> service to resolve the situation. >> >> >> >> I wander is there any way to treat such a cases? May be 'umount -f' can >> >> have more power... >> >> >> >> > So no errors from geom? Or from CAM? what's the underlying storage >> > hardware? And what's the wchan / straceback for the processes in 'D' >> state? >> > And do you know the location of the file that's waiting for I/O? >> >> No errors. UFS was on gmirror and 'gmirror status' said 'OK'. >> Unfortunately I was unable to do meaningful investigation under stress. >> There was a number of smbd process in a jail which ignore killing and >> anything else. >> The first inconsistency found by fsck later was a file with mtime >> corresponding to a first claim of a problem from one user. Hour later there >> was more claims and finally samba share stop working. As I understand UFS >> inconsistency grew over that hour. Because there was multiple smbd >> processes each corresponding to different user there it is no one file >> maked problem. >> >> >> > There's a number of things that might cause this, but they typically are >> > noisy about it. There's a couple of deadlock issues that might cause >> this, >> > but getting some more information is needed to understand what might be >> > done to mitigate or prevent the deadlocks. >> >> > P.S. Previous situation was when I do simple (as I think) experiments >> with >> >> ggated and have forced to reboot server when 'mount' hung. >> >> >> >> > I assume ggate isn't involved when this happens now, right? >> >> That's right. I note this because it seems that stoping ggate server >> while running ggate client is the simplest way to reproduce the problem. >> >> P.S. I was really hope that "umount -f" awake waiting processes for >> killing. >> >> >> >> >> >> -- >> >> Best regards, >> >> Anthony Pankov mailto:anthony.pankov@yahoo.com >> >> >> >> >> >> >> >> >> -- >> Best regards, >> Anthony >> >> -- Best regards, Anthony From nobody Fri Nov 28 13:22:16 2025 X-Original-To: freebsd-hackers@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 4dHv9N5Qd4z6HRH4 for ; Fri, 28 Nov 2025 13:22:32 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 4dHv9N3XGgz3kPY for ; Fri, 28 Nov 2025 13:22:32 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-64320b9bb4bso3668028a12.0 for ; Fri, 28 Nov 2025 05:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764336149; x=1764940949; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=clJf1v6sp9PRytcLp8EzTcj0QjjzsQacUIw7uvRDce4=; b=VT+gH5sgc6yDj1DHPgIOp7Heo4okk9J/F5GVce1pFWq9QkohShzeCaNsOo0WUke8Hb cPWKcv0Y6oKYQW2eN+KGq6A+HJm1S1X91bwfb6KbxiDatAWHSOcV91BmlkeIGPKklMCW r/M+uoNNh0xrQPkabsccTCClAW1uBqdfqDHdLF2tcy1CAksTMFI6KdqHg3RI2KeQZ54R Y6yeMIpDYpHqazp56WcgrefsrIES9BMc4FKiINY12oiQXDfgqQ/ezZ248RcecxYntP7r 3mXr5ueaXgzjECPbAayUpEYE3ADSayQseouIGeNJwjAKfs/pfruLILs62bTF1a/vc4LP 0XXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764336149; x=1764940949; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=clJf1v6sp9PRytcLp8EzTcj0QjjzsQacUIw7uvRDce4=; b=Tjmt2GeVdu2145Soc8Qe9gsrEArPR5y/54vwVh+jT3WkrTn8YPqBG/mPS1TR/17OXK D0X6g33pA8zcFd3VvDruMGPBXAdbPm1VLzHn5fOboB9EMTkBNdtEnxv+IPPd2JWOJnXH c8SgdIEVf63zAysTRKMUeqrJCYQTrPDc77EdHLL9Wt8y1pwor+yv0faow2BYibLrMirC oe04vHoCOzj/8TZf/RjAX18OITjArastUgU7yff2yZitu2fcQXgzoutSp6lE31wBoHPZ e1o1yPG96N6G/DWgpEX2TOspCWJhTHefLw4u00ZBU6Gk4wHUi5Q/nm3dxt4YQxI9e23X k3nw== X-Forwarded-Encrypted: i=1; AJvYcCVSlfl7pjDEamv4P7aTxbT+3ufzTVhaA3HDsfy6YTndwEnGS/wHvKhp1iZzUTQd6YUtmCiuPd32HzmyhOWZR74=@freebsd.org X-Gm-Message-State: AOJu0Yz00/sH7XZDdlQD/RnFhFqtNL5XL3jPSzoeokXz7vTr969PrZ3f l6WEF/fqxzDic8oi1wBZWg1GhM3E/5KQuahsg64umx8BzfI/akOZxvNQkdtpQe4Owzk6ETXqqkq DYsHCEBEqZW4p08iH5y9WqMjMz73rnQ== X-Gm-Gg: ASbGnctCT2C9WUNM7mucHGuQA0pw/WIikrduwnikMUbZMDcklNwvKaiSQYcnefBqnBL jlWLJ3oXnSyOis/IAVx5ogThEyM+Z61tp16DN4lvIas2uOkGk+9br30XwMqH0KaawiirxP9PsJ+ 9yveaiv9HZMd1QSs/DBjtTxtAcHMPYoWZ1JMlxEZTp53poSXCuLxlTXOAoqyzTxIngGsudknJG4 mRiKVT2ou832N3HpAXWm/uiZi668KVRbShq7P47K6IfQvhO1yVEWLzNwMikvefVVUvGA+uGcO5U Ggf3A9mfek8Bnx7oC3Y6oYmpcUVxxq4M4Y9a X-Google-Smtp-Source: AGHT+IFfAS5ZGrcKWa8XuCy0/b0ALpS/KWdj/9p5EzPtBKs7VTP6D1UeUleeLsi79uz23t7sQmr0eNgpEX4Kce8gpUc= X-Received: by 2002:a05:6402:35ca:b0:62e:ebb4:e6e0 with SMTP id 4fb4d7f45d1cf-64555078308mr24091278a12.1.1764336148921; Fri, 28 Nov 2025 05:22:28 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <458400081.20251126171621.ref@yahoo.com> <458400081.20251126171621@yahoo.com> <908785764.20251127131317@yahoo.com> <1777092313.20251128124844@yahoo.com> In-Reply-To: <1777092313.20251128124844@yahoo.com> From: Rick Macklem Date: Fri, 28 Nov 2025 05:22:16 -0800 X-Gm-Features: AWmQ_bkAyq2kFL1gLqAbTotzumgk4cUh2PUtu0VUla1kOBOiMp8E7CjflOIy6zY Message-ID: Subject: Re: any way to recover from I/O hang? To: Anthony Pankov Cc: Warner Losh , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dHv9N3XGgz3kPY On Fri, Nov 28, 2025 at 1:48=E2=80=AFAM Anthony Pankov wrote: > > > Friday, November 28, 2025, 1:06:19 AM, you wrote: > > > Without a wchan waiter or tracebacks, I can't help at all. Nothing you'= ve > > said is actionable, alas. umount should clear everything up, but if you= 've > > hit some bug where the I/O never completes due to deadlock, nothing can > > help you... except maybe tracebacks to we can understand what that dead= lock > > might be. > > I wander do kernel care about infinite I/O waiting? Neither the problem n= or previous situation with ggate doesn't seem like a deadlock for me. > If I remember correctly with ggate reviving ggate server do revive 'hange= d' client which also was unresponsible to -KILL and 'umount -f'. > > Anyway I think it's very desirable that 'umount -f' will apply more for= ce and not give up with "device busy" message. > > I partially understand that "more force" is a complex problem. May be of = something like replacing mountpoint vnode structures by deadfs structures. This is not easy to do (as in unlikely that anyone will ever implement it). The big issue is "if in progress file systems are aborted, data is lost and the file system structure gets messed up". Even if people are willing to live with data loss, there might be new cases that fsck(8) must handle. The exercise of implementing this could be a major project, since all sorts of msleep()s must be changed to return and then all the code that calls them must handle that special case without problems. There is also be lots of waiters on locks and buffer cache blocks that would need to be dealt with. I did "umount -N" for the NFS client, which does what you are asking for and it took quite a while to implement (and I wouldn't be surprised if there is still bugs that make it fail in rare cases). NFS has the advantage that it does not deal with file system structures like inodes and indirect blocks, but it still wasn't easy to get all the "waiters on buffer cache buffers" to error out, etc. As Warner said "If you collect info during the hang and post that, someone might be able to diagnose the problem". As a starting point, the output of "ps axHl" when the hang occurs should show what the various processes are waiting on. Once you have the "wchan" for the processes/threads that are stuck, you can grep around in the sources to find out what it is sleeping on. It might also be a resource exhaustion situation, such as "out of vnodes". I know that, when kern.maxvnodes is exceeded, the system doesn't hang, but it can get so slow that it appears hung. (That one is recognized by threads with a wchan that starts with "v", but I cannot remember the exact wchan.) procstat -kk can also be useful, to figure out what locks various processes are waiting for. rick > > > > On Thu, Nov 27, 2025 at 3:13=E2=80=AFAM Anthony Pankov > > wrote: > > >> > >> Thursday, November 27, 2025, 7:58:21 AM, you wrote: > >> > >> > On Wed, Nov 26, 2025 at 7:16=E2=80=AFAM Anthony Pankov >> > > >> > wrote: > >> > >> >> > >> >> Recently I'm again facing a situation where some UFS (?) error on o= ne > >> >> partition forced me to reboot whole server and interrupt people's w= ork. > >> >> As I understand the brief is: > >> >> > >> >> Reason: A process in state 'D' (uninterruptible wait/sleep) is bloc= ked > >> on > >> >> an I/O operation (e.g., waiting for a network file share, a disk > >> operation, > >> >> or a device that is no longer responding) at the kernel level. The > >> process > >> >> is not awaken to handle signals until the condition it is waiting f= or is > >> >> resolved. > >> >> Solution: You cannot kill a 'D' state process with any signal, incl= uding > >> >> SIGKILL (kill -9). The condition must be resolved (e.g., fixing the > >> network > >> >> connection, waiting for the I/O to time out, or potentially unmount= ing > >> the > >> >> filesystem with umount -f if it's a mounted network share). In some= rare > >> >> cases involving buggy kernel code or hardware failure, a reboot may= be > >> the > >> >> only option. > >> >> > >> >> In my case there was a jailed samba which share one ufs-formatted > >> >> partition. The samba processes hangs one by one and sharing has sto= pped > >> it > >> >> work. > >> >> There was no message in log. Geom reported no errors. Disk's has no > >> error. > >> >> It seems that there was some introduced inconsistency in UFS. > >> >> My thoughts was to stop/kill samba, remove samba's jail, unmount > >> partition > >> >> and do fsck. > >> >> > >> >> But 'jail -r' exit with something 'rc.shutdown exited ... 9' and le= ft > >> jail > >> >> running. pskill -KILL for samba processes say nothing and do nothin= g. > >> >> 'umount -f' say 'Device is busy'. Various utilities such as 'df' ha= ngs. > >> So > >> >> I forced to shutdown the server which has other important and worka= ble > >> >> service to resolve the situation. > >> >> > >> >> I wander is there any way to treat such a cases? May be 'umount -f'= can > >> >> have more power... > >> >> > >> > >> > So no errors from geom? Or from CAM? what's the underlying storage > >> > hardware? And what's the wchan / straceback for the processes in 'D' > >> state? > >> > And do you know the location of the file that's waiting for I/O? > >> > >> No errors. UFS was on gmirror and 'gmirror status' said 'OK'. > >> Unfortunately I was unable to do meaningful investigation under stress= . > >> There was a number of smbd process in a jail which ignore killing and > >> anything else. > >> The first inconsistency found by fsck later was a file with mtime > >> corresponding to a first claim of a problem from one user. Hour later = there > >> was more claims and finally samba share stop working. As I understand= UFS > >> inconsistency grew over that hour. Because there was multiple smbd > >> processes each corresponding to different user there it is no one file > >> maked problem. > >> > >> > >> > There's a number of things that might cause this, but they typically= are > >> > noisy about it. There's a couple of deadlock issues that might cause > >> this, > >> > but getting some more information is needed to understand what might= be > >> > done to mitigate or prevent the deadlocks. > >> > >> > P.S. Previous situation was when I do simple (as I think) experiment= s > >> with > >> >> ggated and have forced to reboot server when 'mount' hung. > >> >> > >> > >> > I assume ggate isn't involved when this happens now, right? > >> > >> That's right. I note this because it seems that stoping ggate server > >> while running ggate client is the simplest way to reproduce the proble= m. > >> > >> P.S. I was really hope that "umount -f" awake waiting processes for > >> killing. > >> > >> > >> > >> > >> >> -- > >> >> Best regards, > >> >> Anthony Pankov mailto:anthony.pankov@yahoo= .com > >> >> > >> >> > >> >> > >> > >> > >> -- > >> Best regards, > >> Anthony > >> > >> > > > -- > Best regards, > Anthony > > From nobody Fri Nov 28 13:36:39 2025 X-Original-To: freebsd-hackers@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 4dHvV94K15z6HSx4 for ; Fri, 28 Nov 2025 13:37:05 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gid2.gid.co.uk (ns0.gid.co.uk [IPv6:2001:470:94de::240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gid2.gid.co.uk", Issuer "gid2.gid.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dHvV83CD7z3m3r for ; Fri, 28 Nov 2025 13:37:04 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gid.co.uk; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 2001:470:94de::240 as permitted sender) smtp.mailfrom=rb@gid.co.uk Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by gid2.gid.co.uk (8.15.2/8.15.2) with ESMTP id 5ASDau4r006200; Fri, 28 Nov 2025 13:36:56 GMT (envelope-from rb@gid.co.uk) Received: from smtpclient.apple ([89.248.30.154]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 5ASDap8A073953; Fri, 28 Nov 2025 13:36:51 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.3\)) Subject: Re: any way to recover from I/O hang? From: Bob Bishop In-Reply-To: <458400081.20251126171621@yahoo.com> Date: Fri, 28 Nov 2025 13:36:39 +0000 Cc: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <23A5EAA0-F4E3-4195-92B1-89A090775282@gid.co.uk> References: <458400081.20251126171621.ref@yahoo.com> <458400081.20251126171621@yahoo.com> To: Anthony Pankov X-Mailer: Apple Mail (2.3826.700.81.1.3) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.30 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[gid.co.uk,none]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FREEMAIL_TO(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4dHvV83CD7z3m3r Hi, > On 26 Nov 2025, at 14:16, Anthony Pankov = wrote: >=20 >=20 > Recently I'm again facing a situation where some UFS (?) error on one = partition forced me to reboot whole server and interrupt people's work. > As I understand the brief is: >=20 > Reason: A process in state 'D' (uninterruptible wait/sleep) is blocked = on an I/O operation (e.g., waiting for a network file share, a disk = operation, or a device that is no longer responding) at the kernel = level. The process is not awaken to handle signals until the condition = it is waiting for is resolved. > Solution: You cannot kill a 'D' state process with any signal, = including SIGKILL (kill -9). The condition must be resolved (e.g., = fixing the network connection, waiting for the I/O to time out, or = potentially unmounting the filesystem with umount -f if it's a mounted = network share). In some rare cases involving buggy kernel code or = hardware failure, a reboot may be the only option. >=20 > In my case there was a jailed samba which share one ufs-formatted = partition. The samba processes hangs one by one and sharing has stopped = it work. > There was no message in log. Geom reported no errors. Disk's has no = error. It seems that there was some introduced inconsistency in UFS. > My thoughts was to stop/kill samba, remove samba's jail, unmount = partition and do fsck. >=20 > But 'jail -r' exit with something 'rc.shutdown exited ... 9' and left = jail running. pskill -KILL for samba processes say nothing and do = nothing. > 'umount -f' say 'Device is busy'. Various utilities such as 'df' = hangs. So I forced to shutdown the server which has other important and = workable service to resolve the situation. >=20 > I wander is there any way to treat such a cases? May be 'umount -f' = can have more power... FWIW I have found in the past that SIGBUS will sometimes unstick a = process that SIGKILL won=E2=80=99t shift. > P.S. Previous situation was when I do simple (as I think) experiments = with ggated and have forced to reboot server when 'mount' hung. >=20 > --=20 > Best regards, > Anthony Pankov mailto:anthony.pankov@yahoo.com >=20 >=20 -- Bob Bishop rb@gid.co.uk From nobody Fri Nov 28 15:09:29 2025 X-Original-To: freebsd-hackers@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 4dHxXV2sjJz6Hf27 for ; Fri, 28 Nov 2025 15:09:14 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Received: from sonic308-18.consmr.mail.ir2.yahoo.com (sonic308-18.consmr.mail.ir2.yahoo.com [77.238.178.146]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dHxXT025lz455Q for ; Fri, 28 Nov 2025 15:09:12 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="rTP/K2Za"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of anthony.pankov@yahoo.com designates 77.238.178.146 as permitted sender) smtp.mailfrom=anthony.pankov@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1764342549; bh=L79py+891KuyJdJhs4OWNKjZXv2a4paZJPEeELwnAF4=; h=Date:From:To:CC:Subject:In-Reply-To:References:From:Subject:Reply-To; b=rTP/K2ZaJuFjzB7d+vopDS3NBa/88YUji6t5miYxPOxfAI5AJgLIHIO8b7wGoJ5JLx7jEt9mkEkFQ3v/mAIDRo7PgiosFKZBlWYscg5OJUz3ukL6NHv6Gd+6B+9Dze0Q1sp1or3pdHpDdsmLZxM4HBWj6M0RhcOhO+0938QkMl/YXjOFZyPXY49BYs4+ASSYzy9NuImY/4tKK68syPKada2yQJF/GmqPgR578rnwbEfGwe7PN9T84yVdjAq2ksxKRkJTMLEvQqzW2/ZzKQX4o6OYHE9Uuq+574pFXwunHB/7eWAWafTny4KunEtfxY24CHcNgJ/ucrnt0p+4x7Lqpw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1764342549; bh=Osti7qbDvWF03FHOZjl2p4tlkNGP5KRFZy6wCbqeYXN=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=RbgIZJ/Ssfh285A9dmdETQrEhi/AiFG56ArlC1yCb8NXU8fWGMPI/2ax2Ql5o0TlAkwPOCwtQ8g5cB3cO+t062mF5CmkdrUNHU9cNAw0U93AhCB0Zt7h1OPdnObPbrJWjZPl3cFoX5IbrFctEb8vMzfk5REF7oJJCx4GuNYi/ECbTKGS0ZzkgJGMX+pTDlMbKWP1KoXjFrKT3zpqjBRJ5Y3R2KVuVvUVp3t45sUP0Mf/GzchJ05qc89SMctXfG5s5gf67UaP9VYYuLMLLefYI44MPrwnPQ3TnbRR7kzBTG+V831TQMHrLcWNs0rx8DqM/Na+JdRs+Ya0CKS6Y3UwOQ== X-YMail-OSG: ZTCjbkYVM1nq4eLJMHruwRwHaZRvl906gKBFmHizxSEC5Z2P1Mefh8ObCfAAZoG YqVfzeiZhx3u7lN6DOUvF1JScnYVHZ7dKvnG8GOBEeI_GLUD.6SxFvqYjtSPRvl5HSW2WUyjPDN8 jEb5.QG733mxbHpHX9wAEm0QbNvzigD36qdPlo0Dr.cxxtEQZDsrplSVjat93fWKaSNt45ofbnFL 0jMgHWC7WHDUIvffs343kPu_SyyJ4g5nDEy0cO1JBGoCim_wXfacsU65vt3OzEPD6aSebbFD5hWi isaqDrTSLum4BpiSBH4t5P1i7e8R070EcpbVk8eAjtTStIWIBXK3oJurMYFHulKRA66c9j1a0LxY kR2_JpAnZyYORLgKVJA4Ian.QF6yK31mpz7AclatQVPpGjuDQszEfJ3zQQAh3IYu9V1kpirlPzHV sFTta3y.3Tfg7mSRVuvdF3gGoJvkJFsCwZosqkKzvM6.ZQVA0l.DAxf0hAmtk9nL3Uw.E7ZqAa7_ xL5cpIaO0Ab9nLfykiuT11onxLqHoNVsS8eUlvo4OzeF5136k810zoUfrpnEE_BseJCPLnROPsB0 gCcnanv5okL7AsRbo46Z3vKbgCRHh3lziC3lJeNwDsRRW1vzT.nxSpYOOEQdDcfwtuSMsDPfalyY DKHVu4n8Eu.Jvq4O8208RuspiP9eZ5s.s2Q098N1I15.rjN_DeRGVJa1ufNzhXGLQ5NsiVT_LgvI tFq2TMxQUstaWuk244UzrXmZ_ea5S2cMfsPp9mdYxcHv_eajQlyIK4FNZsHNH.uDguhrrbI44Rlx mgUy4yGgHAg5OrHf2jD52Yoa_4B3miWu9VDgwJu4gPvF7he4pZK70UHi.wG0GjlqZz6oj6EzkWA0 Qqltas1JhNM4POAEYzhldQZepGi4XIalMaiUcu_vfKnYrWx3VYUsTf2HKN1OoiDVk0bh_rANaaIH .lhRDsWz.eEm4PwtLmp1itHXzGXvm5Z6eH6CKLjZoWHndZA1_I9rShj4CcZgRlotyEOCO4OMQwGt uXI2QDFGp.L7PxXJY5AjMrcJg1SvBcXk9gtymHG3ENa2KQ_s746RDz3n2aDUbnmwnKKF5xEH21aN ZOvDoNt31ifJXy_NvWYsZm0cPsFrOURZZpkoEtAYXOK9E.bI3OiKmATXsbEX7HzETwC4yRKeGaFH LAlzexh8XiNoAmTs4Jo.JEgD_nYXFnIUVFMsT1BSQFC.ZN3Np6WZwc1wbOBdCqUTzXhtA0BdNROU 0POEzw4HMnyK5hoZ9ZVmDc6HVexKV770qBocCZcha5Bi1qi3fgl.0UKzOKRrpUDPjURjPdSrfKPj 7vTd_I4ossCjwSe6bW1vHzS5n8lmQFyTcaKHLiuRixAKrcR.fuZ2DfFVtIYy5yOkcbpwTF4R9LJp 65H6WZvzI9ziHYjE_N7O.5dxwAVEhw.IhnNMbWJNqsKgRQY2Zg_gizi6sGUu86iIJpH7tCRLwEyy zwerfM8PeUHTcsa_9mFR6jDUwBUPCO.3eYgNDSwjPoFjVzs7weO8pVgUyEYy_He20hoOkh87gke4 CPulPrsaZNT6NJx6_yCf71lPQ8isv4Ka2qsd48rEfU0Dtr.je53PL94qLaB4ArHM6FpBZwQRT6U6 TxlmWamgR4MF2hl6iDDKAJqOqoSoyzSS5GZzctvydafMPuyoPjpB0lq_uONHdIRMCD_RJ6LsuDO5 1XjOI1Lr_rG9v8WAd_04OQ2ZTUT01BusJ11Dth8MNNw.HqDZi6vsmHPVnM94Dfn9QQlyBWngAYy1 HQiL0zMWUOqiKB.AubiNI..kY50.u0ZsPd8TuDZFuXCdgHTL6GMOTd.kWTf.33MKmiEGyJIEZ3_t xWyc44HJoagYFp_4CWx8V6e17c.dEivkw39ZqUEPms4v9TM2Kdgl9qeD7xmKx1i7Kml1.fO4NUf. b.Pr7QuIerFcWqrQ3k54h1dAFECTKBIQr_34tOuSVeudHW9u5YwOaL4dmmthy_UykNIOc4bFk5jh nSuJXoDbcM11BsQPYqmBljWoO9bmVCtTLaqdT7vGnc1CcoEmLTyGEWD46_vnl8zZfFFddPKZBJKS UnJ7x6aCbpQ.nL2wjZQs1.Erid7jBx_vHP4r.yOvSK4USNFO514VEaoII4vO0Rzp_NpNY.Abg2DM pWEcKsA9H1ZKWLxIsIK6qcz5AXmDlCBRhe.mT8qNBZ1r_GXCmDHi8.kdBUH_Q.wdBgU2pkORV4MV yRK8e1nufL7Dkh4912VfTyG7. X-Sonic-MF: X-Sonic-ID: 7b3a7f19-e3da-4e0b-b656-abed19e67e60 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ir2.yahoo.com with HTTP; Fri, 28 Nov 2025 15:09:09 +0000 Received: by hermes--production-ir2-76fb978d99-js4tk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a560d5f64d695f96dfe2282ec6b1293f; Fri, 28 Nov 2025 15:09:08 +0000 (UTC) Date: Fri, 28 Nov 2025 18:09:29 +0300 From: Anthony Pankov Message-ID: <101576524.20251128180929@yahoo.com> To: Rick Macklem CC: Warner Losh , freebsd-hackers@freebsd.org Subject: Re: any way to recover from I/O hang? In-Reply-To: References: <458400081.20251126171621.ref@yahoo.com> <458400081.20251126171621@yahoo.com> <908785764.20251127131317@yahoo.com> <1777092313.20251128124844@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.24794 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[77.238.178.146:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:34010, ipnet:77.238.176.0/22, country:GB]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; BLOCKLISTDE_FAIL(0.00)[77.238.178.146:server fail]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[77.238.178.146:from]; TAGGED_RCPT(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4dHxXT025lz455Q =0D=0AFriday, November 28, 2025, 4:22:16 PM, you wrote: >> >> I wander do kernel care about infinite I/O waiting? Neither the problem = nor previous situation with ggate doesn't seem like a deadlock for me. >> If I remember correctly with ggate reviving ggate server do revive 'hang= ed' client which also was unresponsible to -KILL and 'umount -f'. >> >> Anyway I think it's very desirable that 'umount -f' will apply more fo= rce and not give up with "device busy" message. >> >> I partially understand that "more force" is a complex problem. May be of= something like replacing mountpoint vnode structures by deadfs structures. > This is not easy to do (as in unlikely that anyone will ever > implement it). The big issue is "if in progress file systems > are aborted, data is lost and the file system structure gets > messed up". Even if people are willing to live with data > loss, there might be new cases that fsck(8) must handle. I don't think this will introduce new cases for fsck because those situatio= ns ended in cold reboot. System shutdown hangs before any 'syncing' phase. = Aborting in progress filesystem programmatically or doing power off seems f= or me as the same cases for fsck. May be I'm wrong. > The exercise of implementing this could be a major project, > since all sorts of msleep()s must be changed to return and > then all the code that calls them must handle that special case > without problems. There is also be lots of waiters on locks > and buffer cache blocks that would need to be dealt with. > I did "umount -N" for the NFS client, which does what you > are asking for and it took quite a while to implement (and > I wouldn't be surprised if there is still bugs that make it > fail in rare cases). NFS has the advantage that it does > not deal with file system structures like inodes and > indirect blocks, but it still wasn't easy to get all the > "waiters on buffer cache buffers" to error out, etc. From=20my point of view some vnode operation on a mountpont (UFS partition = for samba share) didn't return and stuck somewhere in UFS module. Which mak= e user process (smbd) hang. Then more users process reach something where U= FS stuck. Meanwhile other UFS partitions worked with no problem. This give = me an idea that there is a possibility to release all structures and drop a= ll buffers related to problematic mountpoint keeping server alive. As for server operator "deadlock" in this case mean that there are processe= s which can't be killed because of stuck in failed mount and 'umount -f' th= at can't unmount because of processes used the mount. So I'm here to find a way to give a schedule to a stuck processes just for = killing or to force 'umount -f' release stuck processes and destroy the mou= nt. > As Warner said "If you collect info during the hang and > post that, someone might be able to diagnose the > problem". > As a starting point, the output of "ps axHl" when the > hang occurs should show what the various processes > are waiting on. Once you have the "wchan" for the > processes/threads that are stuck, you can grep around > in the sources to find out what it is sleeping on. > It might also be a resource exhaustion situation, such > as "out of vnodes". I know that, when kern.maxvnodes is > exceeded, the system doesn't hang, but it can get so slow > that it appears hung. (That one is recognized by threads > with a wchan that starts with "v", but I cannot remember > the exact wchan.) No, other services on a server was working well. Sorry for disturbing, this just make some grievance for me because a lot of= work was made to do thing 'right' and to separate services on a server. > procstat -kk can also be useful, to figure out what locks > various processes are waiting for. > rick >> >> >> > On Thu, Nov 27, 2025 at 3:13=E2=80=AFAM Anthony Pankov >> > wrote: >> >> >> >> >> Thursday, November 27, 2025, 7:58:21 AM, you wrote: >> >> >> >> > On Wed, Nov 26, 2025 at 7:16=E2=80=AFAM Anthony Pankov > >> > >> >> > wrote: >> >> >> >> >> >> >> >> Recently I'm again facing a situation where some UFS (?) error on = one >> >> >> partition forced me to reboot whole server and interrupt people's = work. >> >> >> As I understand the brief is: >> >> >> >> >> >> Reason: A process in state 'D' (uninterruptible wait/sleep) is blo= cked >> >> on >> >> >> an I/O operation (e.g., waiting for a network file share, a disk >> >> operation, >> >> >> or a device that is no longer responding) at the kernel level. The >> >> process >> >> >> is not awaken to handle signals until the condition it is waiting = for is >> >> >> resolved. >> >> >> Solution: You cannot kill a 'D' state process with any signal, inc= luding >> >> >> SIGKILL (kill -9). The condition must be resolved (e.g., fixing the >> >> network >> >> >> connection, waiting for the I/O to time out, or potentially unmoun= ting >> >> the >> >> >> filesystem with umount -f if it's a mounted network share). In som= e rare >> >> >> cases involving buggy kernel code or hardware failure, a reboot ma= y be >> >> the >> >> >> only option. >> >> >> >> >> >> In my case there was a jailed samba which share one ufs-formatted >> >> >> partition. The samba processes hangs one by one and sharing has st= opped >> >> it >> >> >> work. >> >> >> There was no message in log. Geom reported no errors. Disk's has no >> >> error. >> >> >> It seems that there was some introduced inconsistency in UFS. >> >> >> My thoughts was to stop/kill samba, remove samba's jail, unmount >> >> partition >> >> >> and do fsck. >> >> >> >> >> >> But 'jail -r' exit with something 'rc.shutdown exited ... 9' and l= eft >> >> jail >> >> >> running. pskill -KILL for samba processes say nothing and do nothi= ng. >> >> >> 'umount -f' say 'Device is busy'. Various utilities such as 'df' h= angs. >> >> So >> >> >> I forced to shutdown the server which has other important and work= able >> >> >> service to resolve the situation. >> >> >> >> >> >> I wander is there any way to treat such a cases? May be 'umount -f= ' can >> >> >> have more power... >> >> >> >> >> >> >> > So no errors from geom? Or from CAM? what's the underlying storage >> >> > hardware? And what's the wchan / straceback for the processes in 'D' >> >> state? >> >> > And do you know the location of the file that's waiting for I/O? >> >> >> >> No errors. UFS was on gmirror and 'gmirror status' said 'OK'. >> >> Unfortunately I was unable to do meaningful investigation under stres= s. >> >> There was a number of smbd process in a jail which ignore killing and >> >> anything else. >> >> The first inconsistency found by fsck later was a file with mtime >> >> corresponding to a first claim of a problem from one user. Hour later= there >> >> was more claims and finally samba share stop working. As I understan= d UFS >> >> inconsistency grew over that hour. Because there was multiple smbd >> >> processes each corresponding to different user there it is no one file >> >> maked problem. >> >> >> >> >> >> > There's a number of things that might cause this, but they typicall= y are >> >> > noisy about it. There's a couple of deadlock issues that might cause >> >> this, >> >> > but getting some more information is needed to understand what migh= t be >> >> > done to mitigate or prevent the deadlocks. >> >> >> >> > P.S. Previous situation was when I do simple (as I think) experimen= ts >> >> with >> >> >> ggated and have forced to reboot server when 'mount' hung. >> >> >> >> >> >> >> > I assume ggate isn't involved when this happens now, right? >> >> >> >> That's right. I note this because it seems that stoping ggate server >> >> while running ggate client is the simplest way to reproduce the probl= em. >> >> >> >> P.S. I was really hope that "umount -f" awake waiting processes for >> >> killing. >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Best regards, >> >> >> Anthony Pankov mailto:anthony.pankov@yaho= o.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Anthony >> >> >> >> >> >> >> -- >> Best regards, >> Anthony >> >> --=20 Best regards, Anthony From nobody Fri Nov 28 16:01:22 2025 X-Original-To: freebsd-hackers@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 4dHyj54SNSz6Hklb for ; Fri, 28 Nov 2025 16:01:45 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 4dHyj36cZxz4G8C for ; Fri, 28 Nov 2025 16:01:43 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-6418b55f86dso3685361a12.1 for ; Fri, 28 Nov 2025 08:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764345696; x=1764950496; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=V6bcBlsqpOcm7WRNYCDwcoeGIGc8PvVbHdRXNszASJc=; b=eu0U0yc+ENEkju+UuVkLKBVzDVFRL3txXVW/aAFG0mG0BGKAg6plwxR5wPsp4lkl2m dW+PNH0rcOFcrx/SGumudqG6TAhmgageIlbwB7by8mvAdhtmsRXo59FZW1f+LEkq0RUc WfzurGGeEmxL0NctdUoRmxYsGJDA/TuxtuksFldVGBUyAtSxzuhtZpD/ameUPheraZl2 Z99CUsWvk6bzAn6xKq4qlN50zSyg127PCxKHBlEGMH3B8WWf6CF7oLtxb8GtgT7mbLZ7 9G1BqxB30RQy3PtainygO9KN1hjOQX3GxTc3VLSGSXkvIaS2fo+szhU6VxhfK+56PLeC 8G+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764345696; x=1764950496; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=V6bcBlsqpOcm7WRNYCDwcoeGIGc8PvVbHdRXNszASJc=; b=mEgzbKPKXKHVWLVu7r96IfBUMtsfUpmf6RA0klt/JnemCIJfa6ivReQ+r2r7M549Qo yCp5uji/naQ1fya9ZKms1p0oChTsBN8NM5i7jOYusxfwn5kVfs0vGIaxsn2xd4T74gIr 7TgfHZ1xW0gPpeGsTUvKd0tJockJAtGTQ0Dx/Mct2MJM3r2n5f3lCXtE4P0HlkhIXJBy 0ai8cntT+wPPiNyyoTD79I5Vvdqf5izOqtE2WsQKdXOAzS4nJWP/F8MlY8dn3LfZE3Th HEBTrHU1Wx5LDoEnR5+JmI57j8LIjKBmW5DCSx4CH7I37WYKvcPpFyK1QcrWJyL7llG3 MSOA== X-Forwarded-Encrypted: i=1; AJvYcCU9CxL6NKoCELohB5sF/sucMT8PfKroIbTDl1VqOfbBuCNFYPylOhZyUFogaIRB023pzd7DyMoplsDUxrNpaok=@freebsd.org X-Gm-Message-State: AOJu0YzZD95qWx7Bzwx/TzAxg4SYPxRNO33KwLS6EYdRmJ14CPgMoHq+ Ysz18kjWYjra8HBTmoTYzYP/7iL3xrSvHf67Cwr096N5k4o/3dLO0TbeuMiHs27pzJkGXjAqFFX fPnLe/HvUckN+L/KJARrSjAt3K5siH8OwhIc= X-Gm-Gg: ASbGnctrGF4eqN3s1lRkrbHGnqVdpqxleJ0Dc9l3wHpDBclVWaaaSgJ8CpQOLBQOhD8 aXoEXdVMkyBqn5IzMIdKIhR5fVKQWLo+IDClyHm79Dn+6JKIPBke9fNZcRGx9yTEA9lxnLqz2pN EjecaeIZ4hIP0t/6j6q/mbF+P4vmt+Qlt577V/Ey5xQ4YYFffUXnrUvGgK6lwS1lIfkirMHKlLV CMyl8ARquMZwMyuc7Lf2mioSqtW/598iVLABJLpytSshgrM46F42qlvXYiP47mUCv0C89Ff8uPu 7pg0ulYvcq6izeZnxiW2cW9v1Q== X-Google-Smtp-Source: AGHT+IE+QwblQq5Zwu3olzbIvstZdFz90CA0ap9cvSWyUVZ9OA9LDIgz/kgMjI1th8gKlZ7/Ye9ZwkQLlurxB10g4Rg= X-Received: by 2002:a05:6402:280c:b0:640:96fe:c7bb with SMTP id 4fb4d7f45d1cf-6455469c726mr28063762a12.28.1764345695048; Fri, 28 Nov 2025 08:01:35 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <458400081.20251126171621.ref@yahoo.com> <458400081.20251126171621@yahoo.com> <908785764.20251127131317@yahoo.com> <1777092313.20251128124844@yahoo.com> <101576524.20251128180929@yahoo.com> In-Reply-To: <101576524.20251128180929@yahoo.com> From: Rick Macklem Date: Fri, 28 Nov 2025 08:01:22 -0800 X-Gm-Features: AWmQ_bn-ertRHX9loNeRhToDnpbsbf2OW1yQVe36pupEibiOmxLi0kXCP78V0CA Message-ID: Subject: Re: any way to recover from I/O hang? To: Anthony Pankov Cc: Warner Losh , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dHyj36cZxz4G8C On Fri, Nov 28, 2025 at 7:09=E2=80=AFAM Anthony Pankov wrote: > > > Friday, November 28, 2025, 4:22:16 PM, you wrote: > > >> > >> I wander do kernel care about infinite I/O waiting? Neither the proble= m nor previous situation with ggate doesn't seem like a deadlock for me. > >> If I remember correctly with ggate reviving ggate server do revive 'ha= nged' client which also was unresponsible to -KILL and 'umount -f'. > >> > >> Anyway I think it's very desirable that 'umount -f' will apply more = force and not give up with "device busy" message. > >> > >> I partially understand that "more force" is a complex problem. May be = of something like replacing mountpoint vnode structures by deadfs structure= s. > > This is not easy to do (as in unlikely that anyone will ever > > implement it). The big issue is "if in progress file systems > > are aborted, data is lost and the file system structure gets > > messed up". Even if people are willing to live with data > > loss, there might be new cases that fsck(8) must handle. > > I don't think this will introduce new cases for fsck because those situat= ions ended in cold reboot. System shutdown hangs before any 'syncing' phase= . Aborting in progress filesystem programmatically or doing power off seems= for me as the same cases for fsck. May be I'm wrong. You might be correct. My understanding (I'm not a UFS guy) is that updates to on-disk storage are done in specific orderings which fsck(8) depends on to fix things. (I think the assumption is that things stop all at once when a crash occurs, but as I said, I'm not a UFS guy). Doing what you want *might* cause partial updates that do not retain that ordering, or maybe the orderings will be retained? rick > > > The exercise of implementing this could be a major project, > > since all sorts of msleep()s must be changed to return and > > then all the code that calls them must handle that special case > > without problems. There is also be lots of waiters on locks > > and buffer cache blocks that would need to be dealt with. > > > I did "umount -N" for the NFS client, which does what you > > are asking for and it took quite a while to implement (and > > I wouldn't be surprised if there is still bugs that make it > > fail in rare cases). NFS has the advantage that it does > > not deal with file system structures like inodes and > > indirect blocks, but it still wasn't easy to get all the > > "waiters on buffer cache buffers" to error out, etc. > > From my point of view some vnode operation on a mountpont (UFS partition = for samba share) didn't return and stuck somewhere in UFS module. Which mak= e user process (smbd) hang. Then more users process reach something where U= FS stuck. Meanwhile other UFS partitions worked with no problem. This give = me an idea that there is a possibility to release all structures and drop a= ll buffers related to problematic mountpoint keeping server alive. > > As for server operator "deadlock" in this case mean that there are proces= ses which can't be killed because of stuck in failed mount and 'umount -f' = that can't unmount because of processes used the mount. > > So I'm here to find a way to give a schedule to a stuck processes just fo= r killing or to force 'umount -f' release stuck processes and destroy the m= ount. > > > As Warner said "If you collect info during the hang and > > post that, someone might be able to diagnose the > > problem". > > As a starting point, the output of "ps axHl" when the > > hang occurs should show what the various processes > > are waiting on. Once you have the "wchan" for the > > processes/threads that are stuck, you can grep around > > in the sources to find out what it is sleeping on. > > > It might also be a resource exhaustion situation, such > > as "out of vnodes". I know that, when kern.maxvnodes is > > exceeded, the system doesn't hang, but it can get so slow > > that it appears hung. (That one is recognized by threads > > with a wchan that starts with "v", but I cannot remember > > the exact wchan.) > > No, other services on a server was working well. > > Sorry for disturbing, this just make some grievance for me because a lot = of work was made to do thing 'right' and to separate services on a server. > > > > procstat -kk can also be useful, to figure out what locks > > various processes are waiting for. > > > rick > > >> > >> > >> > On Thu, Nov 27, 2025 at 3:13=E2=80=AFAM Anthony Pankov > >> > wrote: > >> > >> >> > >> >> Thursday, November 27, 2025, 7:58:21 AM, you wrote: > >> >> > >> >> > On Wed, Nov 26, 2025 at 7:16=E2=80=AFAM Anthony Pankov >> >> > > >> >> > wrote: > >> >> > >> >> >> > >> >> >> Recently I'm again facing a situation where some UFS (?) error o= n one > >> >> >> partition forced me to reboot whole server and interrupt people'= s work. > >> >> >> As I understand the brief is: > >> >> >> > >> >> >> Reason: A process in state 'D' (uninterruptible wait/sleep) is b= locked > >> >> on > >> >> >> an I/O operation (e.g., waiting for a network file share, a disk > >> >> operation, > >> >> >> or a device that is no longer responding) at the kernel level. T= he > >> >> process > >> >> >> is not awaken to handle signals until the condition it is waitin= g for is > >> >> >> resolved. > >> >> >> Solution: You cannot kill a 'D' state process with any signal, i= ncluding > >> >> >> SIGKILL (kill -9). The condition must be resolved (e.g., fixing = the > >> >> network > >> >> >> connection, waiting for the I/O to time out, or potentially unmo= unting > >> >> the > >> >> >> filesystem with umount -f if it's a mounted network share). In s= ome rare > >> >> >> cases involving buggy kernel code or hardware failure, a reboot = may be > >> >> the > >> >> >> only option. > >> >> >> > >> >> >> In my case there was a jailed samba which share one ufs-formatte= d > >> >> >> partition. The samba processes hangs one by one and sharing has = stopped > >> >> it > >> >> >> work. > >> >> >> There was no message in log. Geom reported no errors. Disk's has= no > >> >> error. > >> >> >> It seems that there was some introduced inconsistency in UFS. > >> >> >> My thoughts was to stop/kill samba, remove samba's jail, unmount > >> >> partition > >> >> >> and do fsck. > >> >> >> > >> >> >> But 'jail -r' exit with something 'rc.shutdown exited ... 9' and= left > >> >> jail > >> >> >> running. pskill -KILL for samba processes say nothing and do not= hing. > >> >> >> 'umount -f' say 'Device is busy'. Various utilities such as 'df'= hangs. > >> >> So > >> >> >> I forced to shutdown the server which has other important and wo= rkable > >> >> >> service to resolve the situation. > >> >> >> > >> >> >> I wander is there any way to treat such a cases? May be 'umount = -f' can > >> >> >> have more power... > >> >> >> > >> >> > >> >> > So no errors from geom? Or from CAM? what's the underlying storag= e > >> >> > hardware? And what's the wchan / straceback for the processes in = 'D' > >> >> state? > >> >> > And do you know the location of the file that's waiting for I/O? > >> >> > >> >> No errors. UFS was on gmirror and 'gmirror status' said 'OK'. > >> >> Unfortunately I was unable to do meaningful investigation under str= ess. > >> >> There was a number of smbd process in a jail which ignore killing a= nd > >> >> anything else. > >> >> The first inconsistency found by fsck later was a file with mtime > >> >> corresponding to a first claim of a problem from one user. Hour lat= er there > >> >> was more claims and finally samba share stop working. As I underst= and UFS > >> >> inconsistency grew over that hour. Because there was multiple smbd > >> >> processes each corresponding to different user there it is no one f= ile > >> >> maked problem. > >> >> > >> >> > >> >> > There's a number of things that might cause this, but they typica= lly are > >> >> > noisy about it. There's a couple of deadlock issues that might ca= use > >> >> this, > >> >> > but getting some more information is needed to understand what mi= ght be > >> >> > done to mitigate or prevent the deadlocks. > >> >> > >> >> > P.S. Previous situation was when I do simple (as I think) experim= ents > >> >> with > >> >> >> ggated and have forced to reboot server when 'mount' hung. > >> >> >> > >> >> > >> >> > I assume ggate isn't involved when this happens now, right? > >> >> > >> >> That's right. I note this because it seems that stoping ggate serv= er > >> >> while running ggate client is the simplest way to reproduce the pro= blem. > >> >> > >> >> P.S. I was really hope that "umount -f" awake waiting processes for > >> >> killing. > >> >> > >> >> > >> >> > >> >> > >> >> >> -- > >> >> >> Best regards, > >> >> >> Anthony Pankov mailto:anthony.pankov@ya= hoo.com > >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> >> -- > >> >> Best regards, > >> >> Anthony > >> >> > >> >> > >> > >> > >> -- > >> Best regards, > >> Anthony > >> > >> > > > -- > Best regards, > Anthony > From nobody Fri Nov 28 17:47:31 2025 X-Original-To: freebsd-hackers@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 4dJ13V3JPtz6Hwr7 for ; Fri, 28 Nov 2025 17:47:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 4dJ13V1WVMz3FfX for ; Fri, 28 Nov 2025 17:47:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-3436d6ca17bso2073114a91.3 for ; Fri, 28 Nov 2025 09:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1764352064; x=1764956864; 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=BHVvk7yDUI9ZSU2Kx0kBHDd68MQVN3+lTz2fgn1fmew=; b=zvpipLD/AI2kswueuyTkVea7BWQpD/tzXt0DO2pFqx1mt8bOh6pmuapx2lHRXHNmVk jARrF/WdANqhzH8whWvR0xW7v3SWcQK34OvQW28yXvSSm52Y5FlDB0TgPoflSUEREo1B hdQ1Ga0ExOIS94gUuSToQhGOX3+AWUyC/TmRuSEo27lM+r/c33jNs4uabjjDd7l0x8Qt BrSamVwoedadWHpVS9m0a7Acxl/yj6vlGbyVZ0figZfHCc375I8fJOBDxziP7X68+e35 B+LhN2JuYS+c/nRFlXYvjlND/xlT1jLB8URXYaemXJLQrfk8lqlqK50ijmkvAVoagsZa E2iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764352064; x=1764956864; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BHVvk7yDUI9ZSU2Kx0kBHDd68MQVN3+lTz2fgn1fmew=; b=X9GBwF/8/rHqQGHVGOMYALvrkSZmL4ozyuOTdYxRB8840e4oqTqLp7N9xsv5xS/wyW +LFHJA/5tJ9dujQTT8Qn+5R8OI4+jHIIPbw5Hd8q/hHPubHOh4GVmVaTtNfFdu1qz4Pq zPBuBSJ7O/YP2gMOsZu2Wxe3/UZ6FdA6psi8f+xUBpxzID7Ns7sIGN+jvl8+SG3bCKO2 9H/lp6B18sS8y4ZkrwYNJok5V9/ITA+z46WwbTXontp51d1HScQfQPvxN/BnLj9uPFSA oYLjGmEeziTrvxf4SL96Scc/cbAsGKvJNlbBcKjFNB63TLX4oLNH0b/tK93ORGdkYSp6 yMag== X-Gm-Message-State: AOJu0YxxDQOi/bDhMIWSDVOk2iLmXXAwcc2foj8aI9BC7WJaExvuG6lb jXHO9GypaB/iuyAola7H3sseNjUwbcxj02lh3K5oWlZut/EFjmtRZ3p524zYjr+cwdJhV94Prxz khlZ3qJJNjRz7vNQmE6GBKJKWcaMpVcH1hNgHJtg7/H1NqAba7N/4VL8= X-Gm-Gg: ASbGnctY2S7XImjRYUS2LugPMc50N9gVjRyTiv3CpOwhlUx+DFRKtD7Tl96hZoIQUao zD3+X3indqXgjvxRN7A8E54QcQmoe73j75v9t97IobnMlIbwGJ0hyJN7XxicGDx+kY8MoaVRauc 2ZrPf20Wtv1CyTUR9kfmCY6CbjJLv78w86NJ4SK/pwaH0eaO8PU+qVVBW3mnAHV7R2wjQI+qPJZ wxrVsA3RvXMNI6Tnd5oBgYyity3lnaQerU5xOHJe9/r8QAaHI2Wns9WD8ggl30XzONnThc= X-Google-Smtp-Source: AGHT+IFVfgctuQJhbI+SuyaS6iz4utQ2A3s2XzGECJMwF+oFYL1XAknZDblrDy4NUMLxM8eqkIvSXrH6uQhpagVXGNw= X-Received: by 2002:a17:90b:3e87:b0:340:a1a8:eb87 with SMTP id 98e67ed59e1d1-34733f4f4bamr31904656a91.35.1764352063902; Fri, 28 Nov 2025 09:47:43 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <458400081.20251126171621.ref@yahoo.com> <458400081.20251126171621@yahoo.com> <908785764.20251127131317@yahoo.com> <1777092313.20251128124844@yahoo.com> In-Reply-To: <1777092313.20251128124844@yahoo.com> From: Warner Losh Date: Fri, 28 Nov 2025 10:47:31 -0700 X-Gm-Features: AWmQ_bkewTrxufH6WYpdJQiiE5xJ5tzJDy2f0TPF2G2CYLPDqblqrINot1N27cw Message-ID: Subject: Re: any way to recover from I/O hang? To: Anthony Pankov Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000007262e0644ab3ad4" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dJ13V1WVMz3FfX --00000000000007262e0644ab3ad4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 28, 2025 at 2:48=E2=80=AFAM Anthony Pankov wrote: > > Friday, November 28, 2025, 1:06:19 AM, you wrote: > > > Without a wchan waiter or tracebacks, I can't help at all. Nothing you'= ve > > said is actionable, alas. umount should clear everything up, but if > you've > > hit some bug where the I/O never completes due to deadlock, nothing can > > help you... except maybe tracebacks to we can understand what that > deadlock > > might be. > > I wander do kernel care about infinite I/O waiting? Yes. We try really hard never to wait forever. Waiting forever is a bug. However, there's no way to solve it generically, though. There's no common choke point to use, nor any way to really communicate the underlying system is gone. It all depends on the exact specifics what's wrong and how to fix it. > Neither the problem nor previous situation with ggate doesn't seem like a > deadlock for me. > They are. Whether they seem to you or not, failing to wakeup sleepers is by definition a deadlock. It might not be, exactly, two locked processes waiting for another process to be able to make progress, but it is something that's leaving dangling resources that it didn't clean up and if you don't know why, you can't prevent it in the future. > If I remember correctly with ggate reviving ggate server do revive > 'hanged' client which also was unresponsible to -KILL and 'umount -f'. > I can't debug rumors. I hate to be harsh, but this isn't helpful. It's too vague to be actionable or to explain exactly what happened to bring that situation about at a micro-level. > Anyway I think it's very desirable that 'umount -f' will apply more > force and not give up with "device busy" message. > Yes. I believe in motherhood and apple pie too. I'm wanting to do something to fix any issues we still have here. > I partially understand that "more force" is a complex problem. May be of > something like replacing mountpoint vnode structures by deadfs structures= . Without knowing what the problem is, it's impossible to know if this would work or not. We have to know the specifics in order to know what's going on. We already have all that stuff in place, but if something is sleeping and nobody ever wakes it up, there's nothing to be done except fix that bug. Tossing vague notions about what should be done isn't helpful. Next time this happens, please please please panic the system, take a core dump and contact me so I can get a kernel, the debug symbols and the crash dump to look at. It would be even better if sources / source hash was available. Warner > > On Thu, Nov 27, 2025 at 3:13=E2=80=AFAM Anthony Pankov > > wrote: > > >> > >> Thursday, November 27, 2025, 7:58:21 AM, you wrote: > >> > >> > On Wed, Nov 26, 2025 at 7:16=E2=80=AFAM Anthony Pankov < > anthony.pankov@yahoo.com > >> > > >> > wrote: > >> > >> >> > >> >> Recently I'm again facing a situation where some UFS (?) error on o= ne > >> >> partition forced me to reboot whole server and interrupt people's > work. > >> >> As I understand the brief is: > >> >> > >> >> Reason: A process in state 'D' (uninterruptible wait/sleep) is > blocked > >> on > >> >> an I/O operation (e.g., waiting for a network file share, a disk > >> operation, > >> >> or a device that is no longer responding) at the kernel level. The > >> process > >> >> is not awaken to handle signals until the condition it is waiting > for is > >> >> resolved. > >> >> Solution: You cannot kill a 'D' state process with any signal, > including > >> >> SIGKILL (kill -9). The condition must be resolved (e.g., fixing the > >> network > >> >> connection, waiting for the I/O to time out, or potentially > unmounting > >> the > >> >> filesystem with umount -f if it's a mounted network share). In some > rare > >> >> cases involving buggy kernel code or hardware failure, a reboot may > be > >> the > >> >> only option. > >> >> > >> >> In my case there was a jailed samba which share one ufs-formatted > >> >> partition. The samba processes hangs one by one and sharing has > stopped > >> it > >> >> work. > >> >> There was no message in log. Geom reported no errors. Disk's has no > >> error. > >> >> It seems that there was some introduced inconsistency in UFS. > >> >> My thoughts was to stop/kill samba, remove samba's jail, unmount > >> partition > >> >> and do fsck. > >> >> > >> >> But 'jail -r' exit with something 'rc.shutdown exited ... 9' and le= ft > >> jail > >> >> running. pskill -KILL for samba processes say nothing and do nothin= g. > >> >> 'umount -f' say 'Device is busy'. Various utilities such as 'df' > hangs. > >> So > >> >> I forced to shutdown the server which has other important and > workable > >> >> service to resolve the situation. > >> >> > >> >> I wander is there any way to treat such a cases? May be 'umount -f' > can > >> >> have more power... > >> >> > >> > >> > So no errors from geom? Or from CAM? what's the underlying storage > >> > hardware? And what's the wchan / straceback for the processes in 'D' > >> state? > >> > And do you know the location of the file that's waiting for I/O? > >> > >> No errors. UFS was on gmirror and 'gmirror status' said 'OK'. > >> Unfortunately I was unable to do meaningful investigation under stress= . > >> There was a number of smbd process in a jail which ignore killing and > >> anything else. > >> The first inconsistency found by fsck later was a file with mtime > >> corresponding to a first claim of a problem from one user. Hour later > there > >> was more claims and finally samba share stop working. As I understand > UFS > >> inconsistency grew over that hour. Because there was multiple smbd > >> processes each corresponding to different user there it is no one file > >> maked problem. > >> > >> > >> > There's a number of things that might cause this, but they typically > are > >> > noisy about it. There's a couple of deadlock issues that might cause > >> this, > >> > but getting some more information is needed to understand what might > be > >> > done to mitigate or prevent the deadlocks. > >> > >> > P.S. Previous situation was when I do simple (as I think) experiment= s > >> with > >> >> ggated and have forced to reboot server when 'mount' hung. > >> >> > >> > >> > I assume ggate isn't involved when this happens now, right? > >> > >> That's right. I note this because it seems that stoping ggate server > >> while running ggate client is the simplest way to reproduce the proble= m. > >> > >> P.S. I was really hope that "umount -f" awake waiting processes for > >> killing. > >> > >> > >> > >> > >> >> -- > >> >> Best regards, > >> >> Anthony Pankov mailto: > anthony.pankov@yahoo.com > >> >> > >> >> > >> >> > >> > >> > >> -- > >> Best regards, > >> Anthony > >> > >> > > > -- > Best regards, > Anthony > > --00000000000007262e0644ab3ad4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 28,= 2025 at 2:48=E2=80=AFAM Anthony Pankov <anthony.pankov@yahoo.com> wrote:

Friday, November 28, 2025, 1:06:19 AM, you wrote:

> Without a wchan waiter or tracebacks, I can't help at all. Nothing= you've
> said is actionable, alas. umount should clear everything up, but if yo= u've
> hit some bug where the I/O never completes due to deadlock, nothing ca= n
> help you... except maybe tracebacks to we can understand what that dea= dlock
> might be.

I wander do kernel care about infinite I/O waiting?

Yes. We try really hard never to wait forever. Waiting forever is = a bug. However, there's no way to solve it generically, though. There&#= 39;s no common choke point to use, nor any way to really communicate the un= derlying system is gone. It all depends on the exact specifics what's w= rong and how to fix it.
=C2=A0
Neither the problem nor previous situation with ggate = doesn't seem like a deadlock for me.

They are. Whether they seem to you or not, failing to wakeup=C2=A0sleeper= s is by definition a deadlock. It might not be, exactly, two locked process= es waiting for another process to be able to make progress, but it is somet= hing that's leaving dangling resources that it didn't clean up and = if you don't know why, you can't prevent it in the future.
=C2=A0
If I remember correctly with ggate reviving ggate server do revive 'han= ged' client which also was unresponsible to -KILL and 'umount -f= 9;.

I can't debug rumors. I hate to= be harsh, but this isn't helpful. It's too vague to be actionable = or to explain exactly what happened to bring that situation about at a micr= o-level.
=C2=A0
Anyway I think it's very desirable that=C2=A0 'umount -f'=C2=A0= will apply more force and not give up with "device busy" message= .

Yes. I believe in motherhood and appl= e pie too. I'm wanting to do something to fix any issues we still have = here.
=C2=A0
I partially understand that "more force" is a complex problem. Ma= y be of something like replacing mountpoint vnode structures by deadfs stru= ctures.

Without knowing what the problem is= , it's impossible to know if this would work or not. We have to know th= e specifics in order to know what's going on. We already have all that = stuff in place, but if something is sleeping and nobody ever wakes it up, t= here's nothing to be done except fix that bug. Tossing vague notions ab= out what should be done isn't helpful.

Next ti= me this happens, please please please panic the system, take a core dump an= d contact me so=C2=A0I can get a kernel, the debug symbols and the crash du= mp to=C2=A0look at. It would be even better if sources / source hash was av= ailable.

Warner
=C2=A0
=C2=A0
> On Thu, Nov 27, 2025 at 3:13=E2=80=AFAM Anthony Pankov <anthony.pankov@yahoo.com= >
> wrote:

>>
>> Thursday, November 27, 2025, 7:58:21 AM, you wrote:
>>
>> > On Wed, Nov 26, 2025 at 7:16=E2=80=AFAM Anthony Pankov <anthony.pankov@= yahoo.com
>> >
>> > wrote:
>>
>> >>
>> >> Recently I'm again facing a situation where some UFS = (?) error on one
>> >> partition forced me to reboot whole server and interrupt = people's work.
>> >> As I understand the brief is:
>> >>
>> >> Reason: A process in state 'D' (uninterruptible w= ait/sleep) is blocked
>> on
>> >> an I/O operation (e.g., waiting for a network file share,= a disk
>> operation,
>> >> or a device that is no longer responding) at the kernel l= evel. The
>> process
>> >> is not awaken to handle signals until the condition it is= waiting for is
>> >> resolved.
>> >> Solution: You cannot kill a 'D' state process wit= h any signal, including
>> >> SIGKILL (kill -9). The condition must be resolved (e.g., = fixing the
>> network
>> >> connection, waiting for the I/O to time out, or potential= ly unmounting
>> the
>> >> filesystem with umount -f if it's a mounted network s= hare). In some rare
>> >> cases involving buggy kernel code or hardware failure, a = reboot may be
>> the
>> >> only option.
>> >>
>> >> In my case there was a jailed samba which share one ufs-f= ormatted
>> >> partition. The samba processes hangs one by one and shari= ng has stopped
>> it
>> >> work.
>> >> There was no message in log. Geom reported no errors. Dis= k's has no
>> error.
>> >> It seems that there was some introduced inconsistency in = UFS.
>> >> My thoughts was to stop/kill samba, remove samba's ja= il, unmount
>> partition
>> >> and do fsck.
>> >>
>> >> But 'jail -r' exit with something 'rc.shutdow= n exited ... 9' and left
>> jail
>> >> running. pskill -KILL for samba processes say nothing and= do nothing.
>> >> 'umount -f' say 'Device is busy'. Various= utilities such as 'df' hangs.
>> So
>> >> I forced to shutdown the server which has other important= and workable
>> >> service to resolve the situation.
>> >>
>> >> I wander is there any way to treat such a cases? May be &= #39;umount -f' can
>> >> have more power...
>> >>
>>
>> > So no errors from geom? Or from CAM? what's the underlyin= g storage
>> > hardware? And what's the wchan / straceback for the proce= sses in 'D'
>> state?
>> > And do you know the location of the file that's waiting f= or I/O?
>>
>> No errors. UFS was on gmirror and 'gmirror status' said &#= 39;OK'.
>> Unfortunately I was unable to do meaningful investigation under st= ress.
>> There was a number of smbd process in a jail which ignore killing = and
>> anything else.
>> The first inconsistency found by fsck later was=C2=A0 a file with = mtime
>> corresponding to a first claim of a problem from one user. Hour la= ter there
>> was more claims and finally samba share stop working.=C2=A0 As I u= nderstand UFS
>> inconsistency grew over that hour. Because there was multiple smbd=
>> processes each corresponding to different user there it is no one = file
>> maked problem.
>>
>>
>> > There's a number of things that might cause this, but the= y typically are
>> > noisy about it. There's a couple of deadlock issues that = might cause
>> this,
>> > but getting some more information is needed to understand wha= t might be
>> > done to mitigate or prevent the deadlocks.
>>
>> > P.S. Previous situation was when I do simple (as I think) exp= eriments
>> with
>> >> ggated and have forced to reboot server when 'mount&#= 39; hung.
>> >>
>>
>> > I assume ggate isn't involved when this happens now, righ= t?
>>
>> That's right.=C2=A0 I note this because it seems that stoping = ggate server
>> while running ggate client is the simplest way to reproduce the pr= oblem.
>>
>> P.S. I was really hope that "umount -f" awake waiting pr= ocesses for
>> killing.
>>
>>
>>
>>
>> >> --
>> >> Best regards,
>> >>=C2=A0 Anthony Pankov=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mailto:anthony.pankov@yahoo.com
>> >>
>> >>
>> >>
>>
>>
>> --
>> Best regards,
>> Anthony
>>
>>


--
Best regards,
Anthony

--00000000000007262e0644ab3ad4-- From nobody Sat Nov 29 01:44:00 2025 X-Original-To: freebsd-hackers@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 4dJCdr1QCWz6J5lk for ; Sat, 29 Nov 2025 01:44:48 +0000 (UTC) (envelope-from zagazaw2004@gmail.com) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 4dJCdq3YCVz47cG for ; Sat, 29 Nov 2025 01:44:47 +0000 (UTC) (envelope-from zagazaw2004@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=VB18AZHo; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of zagazaw2004@gmail.com designates 2607:f8b0:4864:20::22a as permitted sender) smtp.mailfrom=zagazaw2004@gmail.com Received: by mail-oi1-x22a.google.com with SMTP id 5614622812f47-450b2715b6cso1126960b6e.0 for ; Fri, 28 Nov 2025 17:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764380681; x=1764985481; darn=freebsd.org; h=content-transfer-encoding:subject:from:to:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=fxkdbg8pJvrTmZfN49oVauv8A0ntTjYBxfreX54xeTE=; b=VB18AZHo99XJ3/v0xZ9ivvf7HaXhJmSay8rAkNkRz4n1PBESQGxKpZp6/uYHUc00BF OlKNbemaBMOqRmnVOqQe5Eklm/fKMJLxi7KOOUnaQfdQBUu8MS5nx423P5jArJJpWVFR rCOB6St3mt+z8gBYuvZh0aOTN651oYYCb2v/iSMoodPPWVfAh0+sWWWB4bpvbPFHorIX cO22r4Elt2hVxY9TFToqPLKYcPcYTHcoE0yd1S+7a0nvkJg3kJ82lbPTtpBBLU4/ie+B Ki9LZMvJBxCs0ZTq/TO/cZ+edh7cMsyD8a2+/tRBQwpMg4j2i6q8Aneptql2SWs1Ij9E YpaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764380681; x=1764985481; h=content-transfer-encoding:subject:from:to:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fxkdbg8pJvrTmZfN49oVauv8A0ntTjYBxfreX54xeTE=; b=CH/+UC6BSS1akgKOPtzgFrNDlklwg6UoDbctlPI7ZChiwS1b0zNosCJFY3aob4FWSd vhAyg7HSwocV17QQut18W9f7q1SDjUhfb3WgZTH5wt56TG+rcqPrGrd7CjG+9e03z0Xt v4OaA0OzrxNr6u2XZZKXAZ8ON9Ts78L5fUX/C/PhNSAGwLPsuQogkl2m5Rt5FnAbDe6o B+RISI6MjV68ZypWb2Sqya+Xvb7zezFAKJoWQAdLxzLbWqacjVt5BMhUqwz4/2JQOLuF uNtHxYNAJ+RsEG52HQoRYK28yATZFwZi58Fg1GsP3YG/x6FOQBWjhl/3klgPTNm+bf+U 6HJw== X-Gm-Message-State: AOJu0YwqpL8PJ+67ff1lhiB01Q9zizZD1w/FjnbWfb5ut/aGYEFm82OS t3CkbMrpiHkSlQ78a/V7EGPHXvNvYM0CQXm+KyrRr+7iZNw0X/ei2VXDvc8xXWDm X-Gm-Gg: ASbGnctETPu6Uz2n9tHJC7lpmAiJzG9Poktv1Jl2scbeiRJmtdaSP5gRUlN2Kn6vaJc dnih4aPGgigHtJTiWDThsNxeJzZ6KM91/gX4FNmtgKlghNSIJy1rNvPCpOwODey6W1QbF2rBoho aNlp5cb5qJvRxbvbcd6MglUZh5C8g0pTPpdNPdN04KhSEzrt9eMklD8540+JpFOjbTPSnlxYQRQ cYxfzQjL8F2RD52TnsaBAaVCk/9gNLIRk1bsoEX47EoONZBPeXgOxbofXsWrielNDwtbHmYSYyW uJPDBmXIhR8tK7mjrFsLRQF82Uj/xfC9OdSp9Ps5KVLel2mkgnWGyxLGHacqOBb2JnxtQO0T1lC j6jD7oEiGZDnOhQDsBwalCFOT5HbldpqOWxz/KVbixFA6ct0Z7PDuDDf0D0e4TiFWmMth0FBQ7d rCl+aUuFd4zfrPJPwcdSzZqe7BikKMQbDfXGU8xescVdUeE6QZKA== X-Google-Smtp-Source: AGHT+IExBx59lzg+LJDE8E4S2OcW11pvBN1twYR2UMMadxjOCZsbvrUDb6x6VMJBm4+Kq9Vdub2n1Q== X-Received: by 2002:a05:6808:3099:b0:44f:e931:38c2 with SMTP id 5614622812f47-4514e62dd4dmr7755990b6e.15.1764380680884; Fri, 28 Nov 2025 17:44:40 -0800 (PST) Received: from [127.0.0.1] (c-76-143-116-34.hsd1.tx.comcast.net. [76.143.116.34]) by smtp.gmail.com with ESMTPSA id 5614622812f47-45317112a7asm1777467b6e.21.2025.11.28.17.44.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Nov 2025 17:44:40 -0800 (PST) Message-ID: <37b16c16-d6fc-4bd3-835d-399c84bdc9f6@gmail.com> Date: Sat, 29 Nov 2025 01:44:00 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org From: Maku Bex Subject: Custom FreeBSD 14.3-RELEASE ISO fails to boot to OS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RECEIVED_HELO_LOCALHOST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22a:from] X-Rspamd-Queue-Id: 4dJCdq3YCVz47cG Hello, I've exhausted myself trying to fix this problem for the past 4 days. x_x I'm following the the FreeBSD docs/manpages (+docs from FreeBSD based flavors) related to building a 14.3-RELEASE ISO, which I succeeded but it fails at boot time. The kernel boots fine as far as I can tell, but 'init.sh' fails at replicating the system image (system.img) to swap. I'm using VirtualBox VM to test the ISO and gave it the following specs: --Disk: 45GB --RAM: 16GB --CPU: 12C The error shows up when this command finishes "dd if=/cdrom/data/system.img status=progress bs=1M | zfs recv -F livecd". This error sounds like it's a corrupt file, but I verified the hash, plus I didn't download it from the wild web for it to be tempered with. ERROR: cannot receive new filesystem stream: incomplete stream Enter full pathname of shell or RETURN for /rescue/sh: When I hit [ENTER], I get "Cannot read termcap database; using dumb terminal settings." Then drops to '#' which is limited and some commands don't work due to "/tmp" not found. Please let me know if I get provide any other info that can help fix this issue. Thanks, From nobody Sat Nov 29 16:00:51 2025 X-Original-To: freebsd-hackers@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 4dJZds42xTz6J869 for ; Sat, 29 Nov 2025 16:01:05 +0000 (UTC) (envelope-from karlo98.m@gmail.com) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 4dJZdr6NMkz3mb2 for ; Sat, 29 Nov 2025 16:01:04 +0000 (UTC) (envelope-from karlo98.m@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=dJqy4YTu; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of karlo98.m@gmail.com designates 2607:f8b0:4864:20::12c as permitted sender) smtp.mailfrom=karlo98.m@gmail.com Received: by mail-il1-x12c.google.com with SMTP id e9e14a558f8ab-4331d3eea61so12238135ab.2 for ; Sat, 29 Nov 2025 08:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764432063; x=1765036863; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Y3axDv6nirysUv8jl4NPv/rfy9YaJuswwCSBAihTBws=; b=dJqy4YTuyDU+SbxeLsZgpaF7S9wVGPRNAgg/LwfUqV9MlYaASAXnAeorK16WKY2X9M SNnAr/C7JhHBAJKRG9rfCaIyCgB6bJmaP4IQ7rDzhF3pUtXvblD0lOipzpmZMe9AwqBS dMuxWHf/Sk6jFVBzdHXGXvxsO9EhJZMzbwE944JyA3+DT2MDehTecEmprw2O1JOJpPvz uAGEO+s0hZSG0Etw3KFADw0wp4torBNH/IWGHbACVxdfyMpUzf7ZxetITWT8mFi/n51Z meEgVMM4MBZRigGwhERkRxjF7V8HsTzjz36A60B/OBeaiwVWaHIGIhxzi5OOEX+wY1hp d7tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764432063; x=1765036863; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Y3axDv6nirysUv8jl4NPv/rfy9YaJuswwCSBAihTBws=; b=FrGHCFcjrKHCcRMH96BNO9HTmHuJ5APP0kdMc8iem6E8CnadOcnrSBuvwQZp2kaVMb 6UEntXspUgK9SMGpH6SGnUWPWm5aBNBDmuxkYVAtaXZuPJXuRL65Puz8Ztyz5NlKB/31 SqJdDgMM1ApWA7PAAJqHBMOBnVS9YjSo2AixGqAlf93dbpExWG+PD4uGFL1eHDw+ELxM FX4MIPVpyxsRuGZFvNGZJw+LmDj6Hj/cSKFaHZZxDCTKiirosQ0xdGkwCmIDddptyJE/ OBVOR3L1QQoCCuI6NSwcAe/LJJADMh+rpkplOlkf9FZ/CMnnfMIdI1I34bb6a+Dyt/9W QtsQ== X-Gm-Message-State: AOJu0Yz0LBrK/PtKGgkGIcAU9AdEcGmbRLjJ9FZopgcv+n9FaUfIEjdh Ju0bbXADpgsfanKx+puAA5Q3S3mCjONnmbHij0aFRia3M8HWMtkq+vgq1y7Ya6rRATcqmb/If4O LjECdQdL3jeynLQJhxW5u4DzrAWebn6hHCs0s X-Gm-Gg: ASbGnctsXgIVNKm1wkZ+ANtY0ZxyHJ22fstUeD2WEAIvhetds21x+FrZ1D33Dl+h+lT 9Z98PfNIhz++pcZNRf027OdXGc2b/31BofXciaPb2/lJuu6OBX/8J1klugAtdbbPYMPWdRdW/9g lTucXOKLWsJDeIIFSOyxkz4ArIYYSe43OvQJ0IM3tnT7LR4ztz8zueN5ddhol+FNZP3K05GysCQ zJB6vxy/e5Z1Jrq491hAl/e5aCB04vspp40L06Qq34fvivVc/ZLu0eXPE7vB21eFGgVam8= X-Google-Smtp-Source: AGHT+IGJusVn7mzafEp0YSEANdCleuvmt0PVOccV1/3MGb98mZHgCu5zzJoFxq/N65MHTEHo9aE/ntEZWBzsw4KKuek= X-Received: by 2002:a05:6e02:2385:b0:434:7a8a:3e0 with SMTP id e9e14a558f8ab-435dd043c3fmr154689585ab.1.1764432062773; Sat, 29 Nov 2025 08:01:02 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 From: =?UTF-8?B?S2FybG8gTWlsacSNZXZpxIc=?= Date: Sat, 29 Nov 2025 17:00:51 +0100 X-Gm-Features: AWmQ_bnx3bbxldbTii84F9BQ8KJBAT958dJCVW3ZfID91jknEnCKkoQRyvksecY Message-ID: Subject: 15.0-RELEASE boot panic when if_iwm_load="YES" To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000054fef10644bdda94" X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; R_MIXED_CHARSET(1.00)[subject]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12c:from] X-Rspamd-Queue-Id: 4dJZdr6NMkz3mb2 --00000000000054fef10644bdda94 Content-Type: text/plain; charset="UTF-8" I know 15.0 is not released yet but the image is up and I wanted to try it out on real hardware. After I put if_iwm_load="YES" in /boot/loader.conf it fails to boot. After saying it's loading loader.conf and briefly flashing FreeBSD logo I get a panic: panic: page fault cpuid = 0 time = 1 KDB: stack backtrace: #0 0xffffffff80bbe1ed at kdb_backtrace+0x5d #1 0xffffffff80b71576 at vpanic+0x136 #2 0xffffffff80b71433 at panic+0x43 #3 0xffffffff81079f69 at trap_pfault+0x3c9 #4 0xffffffff8104ff18 at calltrap+0x8 #5 0xffffffff80c4f974 at namei+0xe4 #6 0xffffffff80c768b2 at vn_open_cred+0x5b2 #7 0xffffffff80bb9ef4 at loadimage+0x274 #8 0xffffffff80bd4de2 at taskqueue_run_locked+0x182 #9 0xffffffff80bd5fb2 at taskqueue_thread_loop+0xc2 #10 0xffffffff80b2786b at fork_exit+0x7b #11 0xffffffff81050f3e at fork_trampoline+0xe Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Am I doing something wrong? IIRC this worked on 14.3 on the same hardware. --00000000000054fef10644bdda94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I know 15.0 is not released yet but the image is up and I = wanted to try it out on real hardware.

After I put if_iwm_load=3D&qu= ot;YES" in /boot/loader.conf it fails to boot.
After saying it'= s loading loader.conf and briefly flashing FreeBSD logo I get a panic:
<= br>panic: page fault
cpuid =3D 0
time =3D 1
KDB: stack backtrace:<= br>#0 0xffffffff80bbe1ed at kdb_backtrace+0x5d
#1 0xffffffff80b71576 at = vpanic+0x136
#2 0xffffffff80b71433 at panic+0x43
#3 0xffffffff81079f6= 9 at trap_pfault+0x3c9
#4 0xffffffff8104ff18 at calltrap+0x8
#5 0xfff= fffff80c4f974 at namei+0xe4
#6 0xffffffff80c768b2 at vn_open_cred+0x5b2<= br>#7 0xffffffff80bb9ef4 at loadimage+0x274
#8 0xffffffff80bd4de2 at tas= kqueue_run_locked+0x182
#9 0xffffffff80bd5fb2 at taskqueue_thread_loop+0= xc2
#10 0xffffffff80b2786b at fork_exit+0x7b
#11 0xffffffff81050f3e a= t fork_trampoline+0xe
Uptime: 1s
Automatic reboot in 15 seconds - pre= ss a key on the console to abort

Am I doing something wrong?
IIRC= this worked on 14.3 on the same hardware.
--00000000000054fef10644bdda94-- From nobody Sat Nov 29 22:25:47 2025 X-Original-To: freebsd-hackers@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 4dJlB72fcxz6J9Hl for ; Sat, 29 Nov 2025 22:26:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dJlB53sHNz3ct2 for ; Sat, 29 Nov 2025 22:26:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=UvtzKX1H; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1764455161; bh=7t8jWjAGeM00+NGfIerR8aiUgs6YKGppq/02EVExYFs=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=UvtzKX1Hy3RI05NlQNPKsHtVsVKsJTRCm6N0T+au7Y0yatftA8tsXH3CUyCDrO+BAtzFsi6ri5zfZ4L+uwZ2JKy0aW9QIAgvgcSpe5u+ii9iphHmXvkwwlqOyo691TxfGTHDLOYDhIvytEOa1WDtuKmEyE6uVGLAQB/GNHWHkWuCtYrThb6JzqaYZZzZGZMdnTrQsCI6LPYHrijC3euUaFsYOQX19Uq38HRDEr275hayuPb4T9KWZJsdsighGXAQ/z079+LjXJowgJJb7s7PO0zrccpH0kMjtTPS+fkuyCxSQITjZjXNg5VQcOfg7iooLFQEoEgR8UPEgN8Im95K0g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1764455161; bh=laM5YLbddh/SlYOrWop9PsS8BwiBWtzTn/pmiVn3oPN=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=OkiZHa/T7K/ULetTI4tmZZV7p7D/G1kNUm99IsVK3fHxgDnGGwp1pxvne9ujZdho+8UrrQEGv/YNiiDjJMyfbmy2v4Ifx5A6R1XYczNNuJ2pS2z3TcDu6PmgT/lIhFtEeMSVF/5OtQyJz/jvD3GsaSLKwz2tRiG7VNk0Qem7kS9uuyh+ElGpO1HKwCcdgqmxxrQ2DPJ/H1EU+q8Y0y2NROA41oqFDC0RHz6WpIxQuZMKDpeQGfjqoS9CmE1DK5KWD4gCjF4VzTgighDDwC9YYFSOW0Ny0gFHjewhhXq7fUvU/+Lq1ts55CuJFR8/OQYqUc+poPgLs1fa2KkF/hHX1A== X-YMail-OSG: IgxmMP0VM1n.C3rtmroZatwvDMLRhpzACiA3tIEJfhmdz0LgxKxnaiWRhvxWMIU xLr0ceFyT7IuuvHZaxaW5bseBDCaNXi6BpDbBPbSJli18Q5uDMyezIEWqAneQi3aWZAMWtggFxDr v1eeCMSmuN2ajTb4dptMzmgxgxD_kYFIxzYV7rSXC3l0D9hEn3mOXhGEgGIUcOIEppTayeopABrb JURFfae9wDgUmBlN54OVHX1Yu5ZifSI9H_aKw4.wcjj5LFYnAf3zg0cl76aJUrSLNbZmLwYc9fF2 mZwBD30IQ.gdnYzP8MXt.pCRv2GUG4Q3I3ML0r1zNSAbW9AxVKLUGsvnSVZeGljfXtzNr0nqAO.A EUl40ghpTylrzqDYZE5a7aKCMTVFt0xnI.7ByTFXl7lPh_EOw_OF320PVz.yQr7aNm1byaulfJGZ 0D_5wADz2HYSgHHQbIRs2bZP_M7G.wyc0klFn_27qIX6o52Ky75ykd6LeTPhLRpd4nOJbHbyHw3Z S6tajE_yWBjJYLNnnyhSGXyY88i0PxljEIODCiea.J88yX.QrJnvBBSMg6I0oQa8y40CNRlsgPlt U04TE3kKBTzAM.08AV5WkX1yhZ6rpfFcCwFRzyviazAzlaGOlev7yj4.Aiu38MRQfBy.S5MIoa4d 82G7D.pFKx3UYN6jsEyvYRKjEQdvmKz1_4TEKmlVz3l.t7yshQE_0dXEGnpsKgZ7r4wW2g8J3oZm rwZLxqXsdDGa_kAiwq5wr3PJxHR7qi3TF7I0xZVAiBmH3hOg6qXdL5Xx38wQTUPZ94aYayIIK5Qg 5ckIeuvSUhi9JeXcz1lyzj5KQ6LMfpvNXHW6h68KGC97Q0peYGoe1.oDdwq94YpXvnTqT8l47yjI xHaYyuyFOjvnljAgEC_9mvlwMMX_lz7yYTWyx3.gDo21YgiTxlShVsYvm3tUZPkYQpGPPX08K0xC BFaieU0876g4NG3CnHhJ59GXh67jzPM4ooCHk0GtUQPwtwFYHJe45f_TdNhkIAwAAP0sdnBxZNtV 9WHRhab4D8h8GbS9vByXN96y.Aie1VekiwmlbCLj6auPedJijb_dd4964bmwe.5M3jfdcTx9JMi4 RmEjLxbRN.CBdqIlNTvLSnavQCuX6gQej0yvJ5iVAoZxAXx7BXbjLIBpShJxk2Y_hVtr9SYjAeSr p02Azn7mOSP61HljRS9r_Pq95apvgqEE.9CnuCMD2qMTLibnYasLnG3TLU6kzT4ZxvDkidqXAOck .EqGI1nPSlo273SFsSmD9LQonnQOYHwv_sBP2F8w.PvK4VnFRAVeIZ7.GKXYFpBkgKcL7Jim3icM NWLs97duEt8pwXnjGqiHo7IvEL8V3f2UKUnjUZ8Yvfzx1VB46qwzg9FJMDrlEUUpkYjDx6QkN6ZJ FWEZ_VPMU74o8ncpyiD8kllRGQ.NinxWnd6HK24Wqcdf8q2T2xoEH13xDgTQ_ra9_a2wUbChgGTd J5_PsyQrS79wPQVDsPE.nZx3XqxPxyggFEyA5x3J6JfOdmlwpzgn1RNwVL9DL.9a7RyfCCuNfxcM rn4LJkLbOYI14AFdRF6Vav_MoCd5suSlve7Kvp001NqPUwPdloJ8x5ZdnOgI8zvgRP7UKerak9zu LseazaOkLGNdi4_qvNumbO40Yxte3C_x8bnsz.mY.gg6fxSeA7K7vnVNf1taJcCBrNdLuUzh3jvA TAr7WsPtCEhNjl1GEF6RmWMzEBQIbr.yud2S02jmJfCbusouLeY6Lb2JNCnns_8_3vNlCe.f8MUx Sha5KxyQjCgVuRH4F2A.a6ob5FhH21x1vl9R6UxfH0b5UxX5BjQw48beypn.4Wd2zjxEZj1CphI1 28AIr.85UHOkHX4GDrpd.mpsdjXkvY7FRVlndil4no30P1xPbvbdrFhVJEldwIduyugeAIMn3INz vqaVGkfZY6o87MVls6pXI2xVR21PZELXO2bpeBqTs.u0UZhEiNeuznOdvtokoTNw.MeNSnLWDOgA 0sx1DzkS.BYX8QtjwvSJ9E2ACoEQ6rbdibxA9nrLQd_pt5Kqhr91xuYnywAWK.EVd06nidKUROTv hZCIRpmXkFyZXPGKN88Tc4zVhpw3xQVwfsYuMYsND6ilbk6Jxl9TIhFKLMy_.yZfOBWn5aLANqnb NS.y7QCCEh_8XffHPri6mrQLXeXIzP6bKMJ9j9opOvBpnU5vtFWMw947BZmsLqonxjECSPropEgo RYoQCM2rS_pYIm9CnGyp9DwJzQavxXEQKNyFmcWnvwKlTnTdBckbS_xQnIshgapU.fFzKbH4Nq8u 4ig-- X-Sonic-MF: X-Sonic-ID: 57427229-e925-4a52-b46f-fb7d22f19424 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 29 Nov 2025 22:26:01 +0000 Received: by hermes--production-gq1-fdb64d996-zqbrv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b04e4ebfe3fa8b9835bb20c30206c11c; Sat, 29 Nov 2025 22:25:58 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: RE: Custom FreeBSD 14.3-RELEASE ISO fails to boot to OS Message-Id: <691F0402-28A5-4827-96FB-5D379C041E29@yahoo.com> Date: Sat, 29 Nov 2025 14:25:47 -0800 To: Maku Bex , freebsd-hackers X-Mailer: Apple Mail (2.3826.700.81) References: <691F0402-28A5-4827-96FB-5D379C041E29.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.43 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.43)[-0.435]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from] X-Rspamd-Queue-Id: 4dJlB53sHNz3ct2 Maku Bex wrote on Date: Sat, 29 Nov 2025 01:44:00 UTC : > I've exhausted myself trying to fix this problem for the past 4 days. x_x > > I'm following the the FreeBSD docs/manpages (+docs from FreeBSD based > flavors) related to building a 14.3-RELEASE ISO, which I succeeded but > it fails at boot time. > The kernel boots fine as far as I can tell, but 'init.sh' fails at > replicating the system image (system.img) to swap. > > I'm using VirtualBox VM to test the ISO and gave it the following specs: > > --Disk: 45GB > --RAM: 16GB > --CPU: 12C > > The error shows up when this command finishes "dd > if=/cdrom/data/system.img status=progress bs=1M | zfs recv -F livecd". As you are not getting help over the holiday weekend, I'll take a partial stab at explaining error message and its context. QUOTE from "man zfs-recv" output: Creates a snapshot whose contents are as specified in the stream provided on standard input. . . . Streams are created using the zfs send subcommand, which by default creates a full stream. END QUOTE Unless /cdrom/data/system.img is the saved output from a "zfs send" command, the byte sequence being processed by the "zfs recv" would not be of the appropriate structure by content as far as I can tell. > This error sounds like it's a corrupt file, Well, a corrupt "zfs send" output instead, from the zfs tool point of view. > but I verified the hash, "zfs send" output is not a simple copy of the byte sequence in any arbitrary file. > plus I didn't download it from the wild web for it to be tempered with. > > ERROR: cannot receive new filesystem stream: incomplete stream "filesystem stream" here is "zfs send" output specifically. > Enter full pathname of shell or RETURN for /rescue/sh: > > When I hit [ENTER], I get "Cannot read termcap database; using dumb > terminal settings." Then drops to '#' which is limited and some commands > don't work due to "/tmp" not found. > > Please let me know if I get provide any other info that can help fix > this issue. === Mark Millard marklmi at yahoo.com