From nobody Sun Jul 16 11:23:07 2023 X-Original-To: fs@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 4R3jWH6zNmz4mt8x for ; Sun, 16 Jul 2023 11:23:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R3jWH4LQ4z4DrT for ; Sun, 16 Jul 2023 11:23:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689506587; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vc4eF9VqUZlaF+7XSI74aIvgc9eg4yI+zFkhpcAYAsM=; b=SPh3IwGy6ThyWol2BBjXHQZ5ZauyIlKViqgF5cBx/1Uhp6xVD5a+/SGTT3ygUJCjHcsHDh oQmkCl0GEIQQbwvnVr4EwwshFKSUlPu1Bx3CjE1beOvfb9KEWv2maX7hW9k6OhYF9wAwgH Kz8gugpGfi/MJ6F6u62GqmB9TNxe7vd6YBfd7LYZyHdw0iS2j/wyYPmYwH2DPzrMKAPJ9/ HnfWg7mr90y1F3yj5XdABe6b5a6HwGRyGMjPFd46Ssqa1Gy9wEgQNAxqH4mYmlWNLkDRjd 6bUSnittMRmynBkIl7Qpu0tHA8s6hXAjNRJnUx2gvtET9NjQly6YhyoULqJr3g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689506587; a=rsa-sha256; cv=none; b=PnpphKHABILEqkWsAgPuYX+rgYtPzSZfoizDDvTVhzTb81wcJFaOD2rzBNNOitcGgGYlIM mrqglVwj3b/8Dblt6ukghZ+vLRgCsEmOUY9ZQZg9gxgu1M3Z/z0RvpTE6uEzshUJmlsre7 JvQNWPxQbHxMsaODou/ltuVLjDFbePSmeah6Pq5XmywiMo26Rj33HgXdqY+v37YV/L/hvQ 8yzslIlN5HbdHTMQD19eszCZvki5k/aldiioH/sLdkX0ed8uF3RrC4frFMKlBpLSLpZ7L4 WoLamkU/HkBIstTUf2MbYWUOUIkpCMW+AUT7NxIHz/acYJCLjxvrv6gvPsNzhA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4R3jWH3RpfzgP8 for ; Sun, 16 Jul 2023 11:23:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 36GBN7QS099041 for ; Sun, 16 Jul 2023 11:23:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 36GBN7nu099039 for fs@FreeBSD.org; Sun, 16 Jul 2023 11:23:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 272325] Page fault, possible ZFS related Date: Sun, 16 Jul 2023 11:23:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pi@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_file_loc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272325 Kurt Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D1= 743 | |72 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Jul 16 14:19:33 2023 X-Original-To: fs@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 4R3nQs51Tjz4nXZ2 for ; Sun, 16 Jul 2023 14:19:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R3nQs3rywz461v for ; Sun, 16 Jul 2023 14:19:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689517173; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fWf3Y3/zrslbDSyKy07UI+4N+pwXHlojfS0eBDAtV0c=; b=IpRdG9IeVyU/WfSdCjlgAL0+XzXfjGAZgShSBOzLpmXfT2lVgv53IME8oco0LOJm1U8ZHR kZYabVdpsVYIK5yGzoDl9xiQtpEJDfQAp+i/3NGy7ohB4voGFTBpd37E0rLSLXgmAJ693T 2VWqgGo49ni1qHbm1T2cOMPdDb8tfsem6o2lPG6kzRpRQyg+O7EQ/lsIVviMaUqqVfQc70 t1RnebUjeI4M8c5r6p1YV6T+eVOD2mOV4iGlPW4xEA4D73zF5qy8C60n5phF0/bHyxJw01 snN3fgdvPHW9ietBf2S4GV75SOWwVrzdODGQnzTtErQGfXAhLKI0Ny1i0HsQqQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689517173; a=rsa-sha256; cv=none; b=sV0Q9ZGLrgLjueEKbX2yHua4kXKDKfH0CPB+VkrTxRcXWUvaS1aJAKFyEN07eo0NNm652w VV+OTcC7gXFlxC07A0yLn8INK8Ui97hf87QpLW+nO+Zenq0JiLdvMEpK57OqMHdmQtY6tV 1aAPOHVPVrRavMwGdf++6q1skM5fCMrkT5+hLdbqhHQf1/b85KM851tdxX4E9bBnVZT7CV 7nqWUkdyZSOaQXTyCIWEnK0qSnYcoTYnmuDeS4ntl5roNWKDAnJh3Lh4u7R45nbhdDb0FA 4WX/hLgm2a3fmWHUFBAs88jM3jWdjQuyrIQJBmn6WoG4rGlwK/0zCWH7hCMYKw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4R3nQs2xD6zlny for ; Sun, 16 Jul 2023 14:19:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 36GEJXYA069828 for ; Sun, 16 Jul 2023 14:19:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 36GEJXN1069827 for fs@FreeBSD.org; Sun, 16 Jul 2023 14:19:33 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 272325] Page fault, possible ZFS related Date: Sun, 16 Jul 2023 14:19:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272325 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D1= 743 | |72 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Jul 16 17:21:26 2023 X-Original-To: fs@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 4R3sSk59bKz4n3n9 for ; Sun, 16 Jul 2023 17:21:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R3sSk30p8z3pmB for ; Sun, 16 Jul 2023 17:21:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689528086; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JieXn8kt4KxUInOqzFEt8HeVrzdJYisjw8BgSeYdzJc=; b=jd/3FZDdJufbUFFeM0LuV4WszwBwpOhqnQVStcwcZ1jgFCemkHlfNLTMQqAeTbe9cxTCWg BB3qXpPEj0+liT1oQDgivFPZcO9Uv31j8PFA3kc0vZExC3w2gQ8X78emTA+KS5n/ks+Rt9 5GibPoB/m4luwUTMxVp0Ye9VcfwGXLlwh+vd+f7+nhP7mOyfcbPClJbWdAqqm/Ckd9njqr 8exKyQMsU6dpDdREjFqsa4wwaL8KRuqzAf71cjMeOpRsGbbDe6aLXWL6UTg8pLUUZCwfOf CLfoThMhYIA2qtR+ORqUPGRfnLoygoIFrZcNPihl2xFeJcgjqg/kaBcXWjr/tA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689528086; a=rsa-sha256; cv=none; b=cwb/cEJFpuTsXe2JPAClQJCXy1zJIT/xb6cyLJ8DfCo896XhRNBl1Q6LAxsyudlaI3PImy 5ZY2YsnZE5C8Jn2Dh4gJeUbuAdkQ3VZ2XHJ4n7Nh/3AIOuSgTUR271IKIWDdk5wcM/6YN5 psHiHvk6xBMEdXOJ/6COE6dt3ipfP0k11En9byCQM70tcy39BapM5cagEND6OLcGLTtH38 7KG6PLlIIxsUxKhzZTpUg0ckjCnYy3MzHG4bYqhwMAaFitJnD3XjMpuIDKKp8knRbAw7vY c0nyUMftUL59AzXwG22CLrhMEelyl+hqxMPEulEj+KoTmZaXZUNppjTUlOAwbA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4R3sSk277vzqk4 for ; Sun, 16 Jul 2023 17:21:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 36GHLQuT035057 for ; Sun, 16 Jul 2023 17:21:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 36GHLQiU035056 for fs@FreeBSD.org; Sun, 16 Jul 2023 17:21:26 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 236357] [zfs] kernel panic on 12-STABLE Date: Sun, 16 Jul 2023 17:21:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236357 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eugen@freebsd.org --- Comment #3 from Eugene Grosbein --- Is this problem still relevant? 12.0-STABLE is EoL. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Jul 16 21:00:28 2023 X-Original-To: fs@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 4R3yKS6DcFz4n4Bs for ; Sun, 16 Jul 2023 21:00:28 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R3yKS1zH8z3sdy for ; Sun, 16 Jul 2023 21:00:28 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689541228; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=XhpeTFpDruyqtIYP1UjqSMJsOoinRWJ0DCKbYLIUNQI=; b=xY5wF43lR3g4KChO3o1xRikWnzdhG0e+Hp2zDbb+sqG5TCV+Gyvk0ApE1euLUCfhbWX1Ib zZfXV+JXqO7x+elQ2rmu4+7u9vfrPriQvpUYT5w9yQhro0Lzf85aB7Wvu8VxfgrM8NYvgm Gj9HkquGUG9RKVgOiGaND15/I9XD0g5T79Je3johxyRFNRFciIExYb6DQQvOsGfhqxQS10 nOB2ThDDssjkGhkjQ3rUxEC3LRh/uZv0FdoxT25fYp/jyfrKoLBiGmldeuH7myaN8YyzDZ +Dghfoh922VtKaHwpAGxmzPmha4aS3vRmNnkQapLlbAeMkd3Jr9uTM584ON4+A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689541228; a=rsa-sha256; cv=none; b=iei/7R775Tb/hkoltxeH6YqshKf5URY2iBcyiVAi8gZiZJj0M31DlgPIcDqdQPa6/B+9V6 vh2rTa4M+bFLmpgVf/xuISnMwZjODBZCN/yyaeUDOoUiya53/QXcxfeGRlW5U4cmfiuOQI 8SJPJAgnSUwjCL10GMN3DYVLSXilK2N/gcPF0epLwswOTUznv5qIjKdrMHwe3L4Br9XGS4 o61VSuIvEn9dPWOKKrrHVqMUoJZrmbQ767mCdg97YWr8Xc7a8azhSuPtPM3FFH7fyNUBti ClV8RRrv7lNWYg0lWIgid0AH0QOHqj0XFAneF1Bbn2qjabl1GzAzT6b+3A5yxg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4R3yKS15cgzxRc for ; Sun, 16 Jul 2023 21:00:28 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 36GL0SYc069854 for ; Sun, 16 Jul 2023 21:00:28 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 36GL0SgR069853 for fs@FreeBSD.org; Sun, 16 Jul 2023 21:00:28 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202307162100.36GL0SgR069853@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: fs@FreeBSD.org Subject: Problem reports for fs@FreeBSD.org that need special attention Date: Sun, 16 Jul 2023 21:00:28 +0000 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16895412280.72Bb7eF.67715" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N --16895412280.72Bb7eF.67715 Date: Sun, 16 Jul 2023 21:00:28 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 237067 | ZFS: Crash in vdev_dtl_reassess when using GELI w Open | 244692 | gjournal: Does not support TRIM Open | 269503 | docs.freebsd.org: default vfs.zfs.arc.meta_limit Open | 271384 | zfs_load is not suitably documented Open | 226130 | ZFS: solaris assert: zrl->zr_refcount == 0 (0x1 = 5 problems total for which you should take action. --16895412280.72Bb7eF.67715 Date: Sun, 16 Jul 2023 21:00:28 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    237067 | ZFS: Crash in vdev_dtl_reassess when using GELI w
Open        |    244692 | gjournal: Does not support TRIM
Open        |    269503 | docs.freebsd.org: default vfs.zfs.arc.meta_limit
Open        |    271384 | zfs_load is not suitably documented
Open        |    226130 | ZFS: solaris assert: zrl->zr_refcount == 0 (0x1 =

5 problems total for which you should take action.
--16895412280.72Bb7eF.67715-- From nobody Mon Jul 17 11:59:32 2023 X-Original-To: freebsd-fs@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 4R4LH24KtMz4nhBn for ; Mon, 17 Jul 2023 11:59:42 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (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 4R4LH10NCtz3lpn for ; Mon, 17 Jul 2023 11:59:40 +0000 (UTC) (envelope-from wjw@digiware.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=digiware.nl header.s=medusa-2017 header.b=CzuDmX44; dkim=pass header.d=digiware.nl header.s=medusa-2017 header.b=CzuDmX44; spf=pass (mx1.freebsd.org: domain of wjw@digiware.nl designates 176.74.240.9 as permitted sender) smtp.mailfrom=wjw@digiware.nl; dmarc=pass (policy=quarantine) header.from=digiware.nl Received: from router10g.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id C24C88B477; Mon, 17 Jul 2023 13:59:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=digiware.nl; s=medusa-2017; t=1689595172; bh=wADoXxccUgMEw7T2WNLG8uBABKgY8sBHO2h6+FtYvX4=; h=Date:To:From:Subject; b=CzuDmX44kgq/6/ulF67kjegdfOeKR6j96UdLgSnL3PQom3ZS1fDxjNq1eXzHXyksz YB4DMy3vRoaqMmaVljF8rFeMl2H5ES3ri/kt+NibDplQEnn+k10QRmzlTdnwx548rJ w1FhoSiOj8jNNvxjYizCM16RYb1dlStJ9yoZxMkZEh6UCKQgnaS6iSGa83N7WczT1R dTGqJP2AKmKG7yVvLXPFrWjk4k5udXRmR36IQbTH1kYU0ookprNXnvyGKF0k5f76Ev kTZcFbVVuC3y6jbju7JeRZ0c6klPHoSW8s+2cXshwD7IZ+oKygmgGgSD+5pELIb3Fn LViQXWvainPZQ== X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by router10g.digiware.nl (router10g.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KpXvb4kus9b; Mon, 17 Jul 2023 13:59:32 +0200 (CEST) Received: from [192.168.101.70] (unknown [192.168.101.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 3D5C78B800 for ; Mon, 17 Jul 2023 13:59:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=digiware.nl; s=medusa-2017; t=1689595172; bh=wADoXxccUgMEw7T2WNLG8uBABKgY8sBHO2h6+FtYvX4=; h=Date:To:From:Subject; b=CzuDmX44kgq/6/ulF67kjegdfOeKR6j96UdLgSnL3PQom3ZS1fDxjNq1eXzHXyksz YB4DMy3vRoaqMmaVljF8rFeMl2H5ES3ri/kt+NibDplQEnn+k10QRmzlTdnwx548rJ w1FhoSiOj8jNNvxjYizCM16RYb1dlStJ9yoZxMkZEh6UCKQgnaS6iSGa83N7WczT1R dTGqJP2AKmKG7yVvLXPFrWjk4k5udXRmR36IQbTH1kYU0ookprNXnvyGKF0k5f76Ev kTZcFbVVuC3y6jbju7JeRZ0c6klPHoSW8s+2cXshwD7IZ+oKygmgGgSD+5pELIb3Fn LViQXWvainPZQ== Message-ID: <82861471-8c7d-a1e0-14aa-9a4e57901af0@digiware.nl> Date: Mon, 17 Jul 2023 13:59:32 +0200 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.13.0 Content-Language: en-US To: FreeBSD Filesystems From: Willem Jan Withagen Subject: Having a disk double listes in a zraid3 pool Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.903]; DMARC_POLICY_ALLOW(-0.50)[digiware.nl,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[digiware.nl:s=medusa-2017]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[digiware.nl:+]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:28878, ipnet:176.74.224.0/19, country:NL]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4R4LH10NCtz3lpn X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi, I admit it is on Linux, but still hope to find the answer here... When Replacing a broken disk I ended up with 2 times the same disk and thus the zraid is in DEGRADED state: pool: zfs-data state: DEGRADED status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-9P scan: resilvered 1.09G in 00:01:10 with 0 errors on Mon Jul 17 13:36:10 2023 config: NAME STATE READ WRITE CKSUM zfs-data DEGRADED 0 0 0 raidz3-0 DEGRADED 0 0 0 sdb ONLINE 0 0 0 sdd ONLINE 0 0 0 sde ONLINE 0 0 0 sdf ONLINE 0 0 0 sdg ONLINE 0 0 0 sdh ONLINE 0 0 0 sdi ONLINE 0 0 0 sdj ONLINE 0 0 0 sdk ONLINE 0 0 0 sdl OFFLINE 0 0 0 sdl ONLINE 0 0 0 raidz3-1 ONLINE 0 0 0 sdm ONLINE 0 0 0 sdn ONLINE 0 0 0 sdo ONLINE 0 0 0 sdq ONLINE 0 0 5 sdp ONLINE 0 0 5 sdr ONLINE 0 0 0 sds ONLINE 0 0 0 sdt ONLINE 0 0 0 sdu ONLINE 0 0 0 sdv ONLINE 0 0 0 sdw ONLINE 0 0 0 sdx ONLINE 0 0 0 errors: No known data errors Any idea how to fix this? Regards, --WjW From nobody Mon Jul 17 12:10:02 2023 X-Original-To: freebsd-fs@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 4R4LW82qK5z4mnjl for ; Mon, 17 Jul 2023 12:10:12 +0000 (UTC) (envelope-from SRS0=ASLf=DD=perdition.city=julien@bebif.be) Received: from orval.bbpf.belspo.be (orval.bbpf.belspo.be [193.191.208.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4R4LW80yfLz3pNG for ; Mon, 17 Jul 2023 12:10:12 +0000 (UTC) (envelope-from SRS0=ASLf=DD=perdition.city=julien@bebif.be) Authentication-Results: mx1.freebsd.org; none Received: from x1 (unknown [212.233.36.45]) by orval.bbpf.belspo.be (Postfix) with ESMTPSA id 284791C45D; Mon, 17 Jul 2023 14:10:05 +0200 (CEST) Date: Mon, 17 Jul 2023 14:10:02 +0200 From: Julien Cigar To: Willem Jan Withagen Cc: FreeBSD Filesystems Subject: Re: Having a disk double listes in a zraid3 pool Message-ID: References: <82861471-8c7d-a1e0-14aa-9a4e57901af0@digiware.nl> List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dha46k3cuatci6g7" Content-Disposition: inline In-Reply-To: <82861471-8c7d-a1e0-14aa-9a4e57901af0@digiware.nl> X-Rspamd-Queue-Id: 4R4LW80yfLz3pNG X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:2611, ipnet:193.191.192.0/19, country:BE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --dha46k3cuatci6g7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 17, 2023 at 01:59:32PM +0200, Willem Jan Withagen wrote: > Hi, >=20 > I admit it is on Linux, but still hope to find the answer here... >=20 > When Replacing a broken disk I ended up with 2 times the same disk How did you replace the broken disk? The correct way is to issue 1) zpool offline, 2) replace physical disk and 3) gpart backup good_disk|gpart restore -F new_disk 4) zpool replace Also, don't forget to boot code on the EFI partition > and thus the zraid is in DEGRADED state: > pool: zfs-data > state: DEGRADED > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are unaffect= ed. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-9P > scan: resilvered 1.09G in 00:01:10 with 0 errors on Mon Jul 17 13:36:10 > 2023 > config: >=20 > NAME STATE READ WRITE CKSUM > zfs-data DEGRADED 0 0 0 > raidz3-0 DEGRADED 0 0 0 > sdb ONLINE 0 0 0 > sdd ONLINE 0 0 0 > sde ONLINE 0 0 0 > sdf ONLINE 0 0 0 > sdg ONLINE 0 0 0 > sdh ONLINE 0 0 0 > sdi ONLINE 0 0 0 > sdj ONLINE 0 0 0 > sdk ONLINE 0 0 0 > sdl OFFLINE 0 0 0 > sdl ONLINE 0 0 0 > raidz3-1 ONLINE 0 0 0 > sdm ONLINE 0 0 0 > sdn ONLINE 0 0 0 > sdo ONLINE 0 0 0 > sdq ONLINE 0 0 5 > sdp ONLINE 0 0 5 > sdr ONLINE 0 0 0 > sds ONLINE 0 0 0 > sdt ONLINE 0 0 0 > sdu ONLINE 0 0 0 > sdv ONLINE 0 0 0 > sdw ONLINE 0 0 0 > sdx ONLINE 0 0 0 >=20 > errors: No known data errors >=20 > Any idea how to fix this? >=20 > Regards, > --WjW >=20 --=20 Julien Cigar Belgian Biodiversity Platform (http://www.biodiversity.be) PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --dha46k3cuatci6g7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEnF27CBNtOraRNmgqCLYqJMpBHmkFAmS1L5YACgkQCLYqJMpB Hmkdsw//Xt9Hhoz+DdAo3bnrYP8+vK/c8cRqZDRNI6OXz75fdsirlTpFVqUFAb1p BH5JnWqiZOCvUR9zP/jNcdPfCkt3S5QoUunVynJNEpIq9J25zmjkzuMqCJabVlF0 haXzpPcDoSXXOjwHy96lQaBBzOsQ43j9yvIzgASWtWRnd4pVCSMRYAEBHDB/3s1a FLf47U5584V0UBHsPkEqgFQI7Wwhqk1gqxdpPelxBlOuwMEepHZgZOP67qHprl3W Y0fH75yzGKFCIR24BVbScy263YUC3n9NFsWJ4lWpv3389pmmilAxRRWz1ZfB9YR7 cPNx9MtshsevFiBNokVNJdooXlYoa+hyXNwlQskZ1L/KPeoaqZJ9ljYKqb8xpLJF Dg99B7zRW3Y3AZXSdXs6P4sx47BZTViRPea7jNEHPx74BBUfVZX8DViGqw0YRTRF NLPuAOvbhR3qIg79pSAcshiNL5GP+Zt11dxZwM33R6IJBn24QfDPHRoLP0enJ8sv wi/iNhMfDk4m1aYRg10Q+dD+iYxqgbvGVFnboCZe5HD7wk7BiB+heSjb+9pQh62S XnZ8j0zZurRC9rEa9QhuXFlVyDRkZrdl4iXGGKgbgyrPWCk9NynNAkUJ5cpRzAUw UOqpw7ZIaL6OWj1WOY+eCGGkSruvqQUxuyv2LMKz3O+kfcraSqM= =4uh9 -----END PGP SIGNATURE----- --dha46k3cuatci6g7-- From nobody Mon Jul 17 12:31:35 2023 X-Original-To: freebsd-fs@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 4R4M016N13z4n08F for ; Mon, 17 Jul 2023 12:31:45 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (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 4R4M015XqFz3vw9 for ; Mon, 17 Jul 2023 12:31:45 +0000 (UTC) (envelope-from wjw@digiware.nl) Authentication-Results: mx1.freebsd.org; none Received: from router10g.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 260C08B796; Mon, 17 Jul 2023 14:31:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=digiware.nl; s=medusa-2017; t=1689597104; bh=y1xyGma6rNQ/E7qm5F0KSHQRcnQBT725Qme5fFz2d60=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=sWW5jy5i/wtE5qhbmNuBTzGfiBTcsYeiEaOAF60QE1sm033f/B1j6ziuTKJcAGMiC sWKK/uEVtNAom1258engrcyjIhXKxykot1nXIgNGCui7bSF1fpjapuiGGFZw/rAb8K XC7wxeJrCbeXyCOgatG9SGeQV1Aaoje+EWfLYXOTd/5GQ3O+RE15xdFlo0uYfSPGPI 0/zzYGrWZpsyZboDGqQrL04bEe7P6TvUIFmcTGX6qPJ3MaTgGTzxa/LRG2uk9PTQhs e/CxV6XVE+qOXWzElJXtg9WoDStw09dkVeQvG86V9uB7EngZ/VvJRhvRsURd6TrrWh AqmxO8rNKCY5A== X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by router10g.digiware.nl (router10g.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd7V_z1jbd3m; Mon, 17 Jul 2023 14:31:42 +0200 (CEST) Received: from [192.168.10.76] (winrack [192.168.10.76]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 7E9768B90D; Mon, 17 Jul 2023 14:31:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=digiware.nl; s=medusa-2017; t=1689597102; bh=y1xyGma6rNQ/E7qm5F0KSHQRcnQBT725Qme5fFz2d60=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=NjP49DE+t58o63SSsnPD07ViAM/LESCBxHkdb6Z5dZW/tpmcXgP7qxnc9QU9eH+vn DJoYktNG2bJ1gtd92KBsJGEmwCSF5etAGtOE6i7fCVzD1pmf7FG6vxIBHQ62e/4RC3 UyJbb+wH1pKhhzqE/8Q89rcyX99HG//5aRlnsjxyDuTmZyhXQiYel4Ve5SoDC+96ZI +kKnkvKvn+itnfvpdqwSoBWQv7ZFyLIG+vbi2LV+27GbRYqqUmoSciIi9xbwGXxrlR nDq3ted8m+AVwA0nayFQW7WL7VniUj+IAPb8no8c9ESTbeZy8I9EsOmSm/lT/2fYda p0LLxh4wFkGpg== Message-ID: <15b852ec-cf95-9203-4a5f-763d1c2b9ba1@digiware.nl> Date: Mon, 17 Jul 2023 14:31:35 +0200 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.13.0 Subject: Re: Having a disk double listes in a zraid3 pool Content-Language: nl To: Julien Cigar Cc: FreeBSD Filesystems References: <82861471-8c7d-a1e0-14aa-9a4e57901af0@digiware.nl> From: Willem Jan Withagen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4R4M015XqFz3vw9 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:28878, ipnet:176.74.224.0/19, country:NL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 17-7-2023 14:10, Julien Cigar wrote: > On Mon, Jul 17, 2023 at 01:59:32PM +0200, Willem Jan Withagen wrote: >> Hi, >> >> I admit it is on Linux, but still hope to find the answer here... >> >> When Replacing a broken disk I ended up with 2 times the same disk > How did you replace the broken disk? > > The correct way is to issue 1) zpool offline, 2) replace physical disk and > 3) gpart backup good_disk|gpart restore -F new_disk 4) zpool replace > > Also, don't forget to boot code on the EFI partition It was a bit more convoluted since it is a disk on an LSI 3108 in jbod mode. So I needed to set JBOD on the disk and reboot. But yes, I first offlined the disk. And after reboot replaced the disk. --WjW > >> and thus the zraid is in DEGRADED state: >> pool: zfs-data >> state: DEGRADED >> status: One or more devices has experienced an unrecoverable error. An >> attempt was made to correct the error. Applications are unaffected. >> action: Determine if the device needs to be replaced, and clear the errors >> using 'zpool clear' or replace the device with 'zpool replace'. >> see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-9P >> scan: resilvered 1.09G in 00:01:10 with 0 errors on Mon Jul 17 13:36:10 >> 2023 >> config: >> >> NAME STATE READ WRITE CKSUM >> zfs-data DEGRADED 0 0 0 >> raidz3-0 DEGRADED 0 0 0 >> sdb ONLINE 0 0 0 >> sdd ONLINE 0 0 0 >> sde ONLINE 0 0 0 >> sdf ONLINE 0 0 0 >> sdg ONLINE 0 0 0 >> sdh ONLINE 0 0 0 >> sdi ONLINE 0 0 0 >> sdj ONLINE 0 0 0 >> sdk ONLINE 0 0 0 >> sdl OFFLINE 0 0 0 >> sdl ONLINE 0 0 0 >> raidz3-1 ONLINE 0 0 0 >> sdm ONLINE 0 0 0 >> sdn ONLINE 0 0 0 >> sdo ONLINE 0 0 0 >> sdq ONLINE 0 0 5 >> sdp ONLINE 0 0 5 >> sdr ONLINE 0 0 0 >> sds ONLINE 0 0 0 >> sdt ONLINE 0 0 0 >> sdu ONLINE 0 0 0 >> sdv ONLINE 0 0 0 >> sdw ONLINE 0 0 0 >> sdx ONLINE 0 0 0 >> >> errors: No known data errors >> >> Any idea how to fix this? >> >> Regards, >> --WjW >> From nobody Mon Jul 17 12:43:36 2023 X-Original-To: freebsd-fs@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 4R4MFl3JSqz4n5Mc for ; Mon, 17 Jul 2023 12:43:39 +0000 (UTC) (envelope-from SRS0=ASLf=DD=perdition.city=julien@bebif.be) Received: from orval.bbpf.belspo.be (orval.bbpf.belspo.be [193.191.208.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4R4MFl2XwJz40TB for ; Mon, 17 Jul 2023 12:43:39 +0000 (UTC) (envelope-from SRS0=ASLf=DD=perdition.city=julien@bebif.be) Authentication-Results: mx1.freebsd.org; none Received: from x1 (unknown [212.233.36.45]) by orval.bbpf.belspo.be (Postfix) with ESMTPSA id DD08A1C5BC; Mon, 17 Jul 2023 14:43:38 +0200 (CEST) Date: Mon, 17 Jul 2023 14:43:36 +0200 From: Julien Cigar To: Willem Jan Withagen Cc: FreeBSD Filesystems Subject: Re: Having a disk double listes in a zraid3 pool Message-ID: References: <82861471-8c7d-a1e0-14aa-9a4e57901af0@digiware.nl> <15b852ec-cf95-9203-4a5f-763d1c2b9ba1@digiware.nl> List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eszeibxw3z75no55" Content-Disposition: inline In-Reply-To: <15b852ec-cf95-9203-4a5f-763d1c2b9ba1@digiware.nl> X-Rspamd-Queue-Id: 4R4MFl2XwJz40TB X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:2611, ipnet:193.191.192.0/19, country:BE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --eszeibxw3z75no55 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 17, 2023 at 02:31:35PM +0200, Willem Jan Withagen wrote: > On 17-7-2023 14:10, Julien Cigar wrote: > > On Mon, Jul 17, 2023 at 01:59:32PM +0200, Willem Jan Withagen wrote: > > > Hi, > > >=20 > > > I admit it is on Linux, but still hope to find the answer here... > > >=20 > > > When Replacing a broken disk I ended up with 2 times the same disk > > How did you replace the broken disk? > >=20 > > The correct way is to issue 1) zpool offline, 2) replace physical disk = and > > 3) gpart backup good_disk|gpart restore -F new_disk 4) zpool replace > >=20 > > Also, don't forget to boot code on the EFI partition > It was a bit more convoluted since it is a disk on an LSI 3108 in jbod mo= de. > So I needed to set JBOD on the disk and reboot. What do you mean by "set JBOD on the disk"..? > But yes, I first offlined the disk. > And after reboot replaced the disk. After replacing the physical disk did you issued zpool replace? It looks like you used zpool online instead of zpool replace >=20 > --WjW >=20 > >=20 > > > and thus the zraid is in DEGRADED state: > > > pool: zfs-data > > > state: DEGRADED > > > status: One or more devices has experienced an unrecoverable error. = An > > > attempt was made to correct the error. Applications are una= ffected. > > > action: Determine if the device needs to be replaced, and clear the e= rrors > > > using 'zpool clear' or replace the device with 'zpool replac= e'. > > > see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-9P > > > scan: resilvered 1.09G in 00:01:10 with 0 errors on Mon Jul 17 13:= 36:10 > > > 2023 > > > config: > > >=20 > > > NAME STATE READ WRITE CKSUM > > > zfs-data DEGRADED 0 0 0 > > > raidz3-0 DEGRADED 0 0 0 > > > sdb ONLINE 0 0 0 > > > sdd ONLINE 0 0 0 > > > sde ONLINE 0 0 0 > > > sdf ONLINE 0 0 0 > > > sdg ONLINE 0 0 0 > > > sdh ONLINE 0 0 0 > > > sdi ONLINE 0 0 0 > > > sdj ONLINE 0 0 0 > > > sdk ONLINE 0 0 0 > > > sdl OFFLINE 0 0 0 > > > sdl ONLINE 0 0 0 > > > raidz3-1 ONLINE 0 0 0 > > > sdm ONLINE 0 0 0 > > > sdn ONLINE 0 0 0 > > > sdo ONLINE 0 0 0 > > > sdq ONLINE 0 0 5 > > > sdp ONLINE 0 0 5 > > > sdr ONLINE 0 0 0 > > > sds ONLINE 0 0 0 > > > sdt ONLINE 0 0 0 > > > sdu ONLINE 0 0 0 > > > sdv ONLINE 0 0 0 > > > sdw ONLINE 0 0 0 > > > sdx ONLINE 0 0 0 > > >=20 > > > errors: No known data errors > > >=20 > > > Any idea how to fix this? > > >=20 > > > Regards, > > > --WjW > > >=20 >=20 --=20 Julien Cigar Belgian Biodiversity Platform (http://www.biodiversity.be) PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --eszeibxw3z75no55 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEnF27CBNtOraRNmgqCLYqJMpBHmkFAmS1N3QACgkQCLYqJMpB Hmk8+w//b6IHJJv4W2mi1PzSk3nrL92z+LQj4YK4U0TQvKawubAzTaZvKcdD77LK mQzowAKBuqexb+t2XZKD7ZQdPmzYybhKpujI1bFl9wqyetXmTY0TMV/fR0CcBBg8 VNh4RAcoYc2JqTGk7Ixh56p7XnLWeG3ZQ9Ktmq5Zz5sIkRdv+ywoi2wVdcDiyXWP CubZmaisBHWZsGlAeg9AYqGPEBFMOYM4saxyMc1KnePSMQNkwYBbd5+gRQIIllB4 /ea9hXQ30B871cTx9AWXGOiSfJcIi/6oYKzjGPd9IVbmxXQW+Uux5lfb8mOSJgCA EOMK7Zd25+IqucslxlZEKH4eXOPJ8zuFTsM5oe3owWsa81nCrOJA+HXmI1BTqz0F lIqbMnBzOG93+TOVqCGRgIHRK2RSVK0TCxDkRuagdtGYBHbpPfc4xbB49hs/NfCT ePdetjPmL9opUrnzN8Pr3ekwhrqyADdlBpYHABj/nFGYd7Lqn21FIiqgoLAKW4lr zCwk1YIMboM6WPulw3VFmR4emQKlZHFkGFxRlRPQzvovHIhhmQiWQ/DjVhMz6QBh clHaYzsNRKESPJIAuzv5PFuUQhP3az40JbMQJDlQMesc3tQq8yI2BaJuh9EaVoLj GVFggyrIe5Q//SoYQHSMfzCySBUL4PYm0y6Tja3G6v7oYiNdtz4= =NHJ5 -----END PGP SIGNATURE----- --eszeibxw3z75no55-- From nobody Tue Jul 18 09:22:35 2023 X-Original-To: fs@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 4R4tlH4SwRz4kQ30 for ; Tue, 18 Jul 2023 09:22:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R4tlH2YMfz3N2c for ; Tue, 18 Jul 2023 09:22:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689672155; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Cq8fi2rSCIyJvsLXOgo1j8JGco0kCHqivbbk+JHhv78=; b=bVonshfJnVTpxj86fbZc538J2x9bHGIugOqpB5LmpIAtOZr1P4NeI75WQMdZA0VLGd9LXD 62Jq0M2jrvvWQ8Sh8T71ss3eLWuwHhPrG74C8oZcZwl98QC/IsI+Z9byPAUZOmuc0II85U UIOfe5RdhFadsXR98fnZ3G6wUgXuK8gF0UZ2oVsm2qujAPUQ22JpleqQaMxc8eFaktlkMK wfpcez1gO6j3ciEV8MMzgW3iF4s7pBPEIF+bbkKOFO/tf/hWVKE3/2sGJE1gyXqFAnNL8V EP1h1fUlsokpA8pA36u+5GkehoKkijaQev79U7fkDIjJZ6LhYE+Swc3xRRN+eg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689672155; a=rsa-sha256; cv=none; b=dAlLJTUREru0hvEF3fRBQuU+6xGJRLNxHKicXf/OEa38DXc9h5ZhZsb7YoQXygaYuD+wPI okG30RLjsC6raZkPAgmCkB5ov+zvhsd7JvQ2FoukR/ANUfCBmY006AMU+GhdQQMiUoAJbP wtvfqznyXgN/aKAS8fZO69U8ZhSq0GtuJzKIsa5qOmkYDkkhRG2a6QHhOvC/0LN5vVxGdQ GOnHPmmWCcqqB5D+9jye4kXW3Wes85nI22y/cA6wVf/K+cJnwkdi7I3HeDdN4NCmQAsFYO J9kLY8V1qcq+kJKXsQok9uDQafDFYyMqt1jOs1YDTv3CkGNSGxysOmEQzY5Dlw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4R4tlH1cBdz10sX for ; Tue, 18 Jul 2023 09:22:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 36I9MZgd006709 for ; Tue, 18 Jul 2023 09:22:35 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 36I9MZdl006708 for fs@FreeBSD.org; Tue, 18 Jul 2023 09:22:35 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 264234] "zpool get autotrim" displays propety as default regardless of value Date: Tue, 18 Jul 2023 09:22:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264234 --- Comment #7 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3Db36f469a15ecf508a2fdc2b58a76f0f2b= 4a0b88d commit b36f469a15ecf508a2fdc2b58a76f0f2b4a0b88d Author: Yuri Pankov AuthorDate: 2023-07-17 09:12:53 +0000 Commit: Yuri Pankov CommitDate: 2023-07-18 09:20:11 +0000 zfs: set autotrim default to 'off' As it turns out having autotrim default to 'on' on FreeBSD never really worked due to mess with defines where userland and kernel module were getting different default values (userland was defaulting to 'off', module was thinking it's 'on'). PR: 264234 Reviewed by: mav (zfs) Differential Revision: https://reviews.freebsd.org/D41056 sys/conf/kern.pre.mk | 3 +-- sys/contrib/openzfs/include/sys/spa.h | 6 ------ sys/contrib/openzfs/module/zcommon/zpool_prop.c | 2 +- sys/modules/zfs/Makefile | 2 +- 4 files changed, 3 insertions(+), 10 deletions(-) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Jul 18 09:24:58 2023 X-Original-To: fs@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 4R4tp22LgSz4kR0k for ; Tue, 18 Jul 2023 09:24:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R4tp20S6zz3Npq for ; Tue, 18 Jul 2023 09:24:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689672298; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Em1yZajyztHdApO7iXxjQuaLF/g/mbRluMD/vFCa5F8=; b=X3sj9Ek3PzifjIxIScFqFKrMUMgypGHYsMaaDEHAkZCoRqbGoZyAtE7iGiEyiI74V5ZXWm E97gV3R9o6VtGVCoH2Io1H2qdv3IKJpeaksBe8Vz2+qj/ueN3qhBjnONlQsHZNlaP8ousV DOeotPbm0kCLK3UQl5OY9NhVzxcSWIUAgmolejOrAHV5Cnp4iuuSXA/lpea4Rl16hiXv5p pGnnkqkFNdUzEX+gXR0Bsliu7x5rcA6HafnutlSwCHBS5fLOGVoUgzAfkCd65ce99pEj/s XK6czrOiFxz7vJTh+hSYm7FSob+hqP9RQuQDbAnYZjNjGBeHYLqnHZGDqXTu8w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689672298; a=rsa-sha256; cv=none; b=KCP+FmFdaTmPVe/rYCMEP+7etglBfoiml2/Iuh4mUsHEWBId/TL1H+HtL3YLr5K7MH02X9 JIBFsLMKcNdVXsOIA7fml6Srby5Ulf/5XNjddp8CGzcD7biN3LlFishnId3fQTUaB9G4mi NazNyLsyubrmfEqYdIM4MubaO5ZjEU31FEVidJ8GqPQDKVCn2y9n8Ne6CAtVa1j+IaigX+ u9YCG1PVn1fZmDj55fTscHDTAN4oxw9dyadjz2L19KelwMxGhIGfQCoZE/iVUbMbGlBDsv H9Uv1lIeY/Og9qJ/1YVPGhN0kcREIWeBRqoQhvtmifzGXopZhTirAhcMVQHVtw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4R4tp16VJQz10sZ for ; Tue, 18 Jul 2023 09:24:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 36I9OvKv007582 for ; Tue, 18 Jul 2023 09:24:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 36I9OvHb007581 for fs@FreeBSD.org; Tue, 18 Jul 2023 09:24:57 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 264234] "zpool get autotrim" displays propety as default regardless of value Date: Tue, 18 Jul 2023 09:24:58 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: yuripv@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: yuripv@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to cc bug_file_loc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264234 Yuri Pankov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |In Progress Assignee|fs@FreeBSD.org |yuripv@FreeBSD.org CC| |fs@FreeBSD.org URL|https://reviews.freebsd.org |https://reviews.freebsd.org |/D40075 |/D41056 --- Comment #8 from Yuri Pankov --- Just a note here: autotrim was really defaulting to 'off' (due to confusion with defines) despite the attempt to keep it as 'on' when switching to open= zfs, so man page is correct (even if by coincidence). --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From nobody Tue Jul 18 11:20:29 2023 X-Original-To: freebsd-fs@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 4R4xMP56lQz4h3Sd for ; Tue, 18 Jul 2023 11:20:33 +0000 (UTC) (envelope-from kekek2@ya.ru) Received: from forward400b.mail.yandex.net (forward400b.mail.yandex.net [IPv6:2a02:6b8:c02:900:1:45:d181:db01]) (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 4R4xMP06dgz45pB for ; Tue, 18 Jul 2023 11:20:33 +0000 (UTC) (envelope-from kekek2@ya.ru) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ya.ru header.s=mail header.b=fjFZVjnJ; spf=pass (mx1.freebsd.org: domain of kekek2@ya.ru designates 2a02:6b8:c02:900:1:45:d181:db01 as permitted sender) smtp.mailfrom=kekek2@ya.ru; dmarc=pass (policy=none) header.from=ya.ru Received: from mail-nwsmtp-mxback-production-main-35.iva.yp-c.yandex.net (mail-nwsmtp-mxback-production-main-35.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:428c:0:640:9222:0]) by forward400b.mail.yandex.net (Yandex) with ESMTP id 971C86365D for ; Tue, 18 Jul 2023 14:20:29 +0300 (MSK) Received: from mail.yandex.ru (2a02:6b8:c0c:5baa:0:640:2bf9:0 [2a02:6b8:c0c:5baa:0:640:2bf9:0]) by mail-nwsmtp-mxback-production-main-35.iva.yp-c.yandex.net (mxback/Yandex) with HTTP id SKefh90WASw0-qYrrx0zk; Tue, 18 Jul 2023 14:20:29 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1689679229; bh=Hhu+q/dw7Zn3vNWYS5ZkO7oF99O1ChsqgbG+r7BMnBE=; h=Message-Id:Date:Subject:To:From; b=fjFZVjnJWz9GmqIzzq0472EdF6WJ1yIRRIqQdcTtJ4oAfQKpkOfKMuf9LNHuVgwGo NHXN7yFp1Fxuv39YkC6RpAFSvvpDscwduelnGC45UpEE0lRMmTYCOagan0rinr178B KqRaYb7uQ9dxjWLLaM8pPhXWRkMh+qEn1LsgC7zQ= Received: by 2y2i6g6snfcuakol.iva.yp-c.yandex.net with HTTP; Tue, 18 Jul 2023 14:20:29 +0300 From: Alexander Shursha Envelope-From: kekek2@yandex.ru To: "freebsd-fs@FreeBSD.org" Subject: Editing nullfs file List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 18 Jul 2023 14:20:29 +0300 Message-Id: <505731689678939@mail.yandex.ru> Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=utf-8 X-Spamd-Result: default: False [1.10 / 15.00]; NEURAL_SPAM_LONG(1.00)[0.999]; NEURAL_SPAM_SHORT(0.64)[0.642]; DMARC_POLICY_ALLOW(-0.50)[ya.ru,none]; MIME_HTML_ONLY(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:c00::/40:c]; R_DKIM_ALLOW(-0.20)[ya.ru:s=mail]; NEURAL_SPAM_MEDIUM(0.16)[0.163]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; TO_DN_EQ_ADDR_ALL(0.00)[]; MIME_TRACE(0.00)[0:~]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[ya.ru]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; FREEMAIL_FROM(0.00)[ya.ru]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[ya.ru:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4R4xMP06dgz45pB X-Spamd-Bar: +
Hi!
I do the following:
 
mkdir -p /mnt
touch /mnt/foo
mount -t nullfs /COPYRIGHT /mnt/foo
sed -i 's/Berkeley//' /COPYRIGHT
diff /COPYRIGHT /mnt/foo
 
The files are different. Is this normal behavior or a bug ?
 
From nobody Thu Jul 20 22:50:15 2023 X-Original-To: freebsd-fs@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 4R6SZX1v6yz4nMt4 for ; Thu, 20 Jul 2023 22:50:28 +0000 (UTC) (envelope-from rick.macklem@gmail.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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R6SZV6lR6z4KGp; Thu, 20 Jul 2023 22:50:26 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=oJMZhfDs; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::1035 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-262e04a6f66so643662a91.0; Thu, 20 Jul 2023 15:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689893426; x=1690498226; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=V6r6nIIckHvt4azNEJvvoRRWzEUU1clZtm43lFi/Pdc=; b=oJMZhfDs6PrTZzFZVkgUwxkavbNQUSH0FqtS9M9U+M9OkQHA95uVetH7ZUjCpSJHAG lEWL1Uf2dNVRVbhLcxLoTgu2DCDITTciaaizKLqQ+5c8gsiABhYM6YNCcxJsCz+b6Y3R nvHisbOqBoHoRi2Pnbke8Xsy7JwSbiUg77uIgj8tqRjxPeyQw7rRsSwCkKctVKcdRtK6 kkB+naIJqF/oR1GfgFXB+2OW46O/sqAzj+S/PaYnUdN68hi242jqiCEJ7zDUO9VKOBEY Wqobr0rtbPKEjJ0N5PeCmuc+srzGlSzcGy4lyFeDINXmm8tKoz7fWglwk36mgmZa+VZh a8Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689893426; x=1690498226; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=V6r6nIIckHvt4azNEJvvoRRWzEUU1clZtm43lFi/Pdc=; b=IPGwmYImNNi0Bmh0lTvwWaE4k2JQ7XJ3X4CisB+aHw6OgdryEv9PBzub/twN8bx3ht VxXvqQOcUdTX6Lmr+6CDA/vgPtHfL4ZSrDS6mz9nH9FPsrA3e4Af4r1UOXtU5usV5r2F kcvWYd4icobYoYXNpMYQAOgo16/7Gs3H53u/Tw4mEpg108a57q5fsyWnbYALYlruuo0H 9w3GmewRu1m1D7lRV6+bVHGh1QaNnmkLKVRQy2DjuvlpBX3nEgbjJsEounuhvOQR52e8 vIX+XqaMdn1Nzd/u3U7CWs/sZ5GuCku5muktPjobcsQiSoWbLwcqc2m30xZ+tDwy3wM5 E6Tw== X-Gm-Message-State: ABy/qLbgnFuZFmA+sP2JQ+hmii3tl8a238dmK8zSp1G4p4LKcccCUGrU rr0ICvReuWFSb+GcTD/SnUB7J/dZ8WQM6rkbn4dviu6ubg== X-Google-Smtp-Source: APBJJlEZ/VgvJAAmeAJCjaMimt1I97N7B2vB0B36z3Zzy1yUq9tmPLx0GJXosgGwva4wfsE5nSelvgk+mnFwH3wvxyw= X-Received: by 2002:a17:90a:300e:b0:259:a879:cb8f with SMTP id g14-20020a17090a300e00b00259a879cb8fmr76316pjb.7.1689893425675; Thu, 20 Jul 2023 15:50:25 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 From: Rick Macklem Date: Thu, 20 Jul 2023 15:50:15 -0700 Message-ID: Subject: RFC: Patch for mountd to handle a database for exports To: Freebsd fs , Peter Eriksson , kevans@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.995]; NEURAL_HAM_SHORT(-0.99)[-0.989]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::1035:server fail]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1035:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4R6SZV6lR6z4KGp X-Spamd-Bar: --- Hi, Peter Eriksson has submitted an interesting patch that adds support for a database file for exports. My understanding is that this improves performance when used with the ZFS share property for exporting a large number of file systems. There are a couple of user visible issues that I'd like feedback from others. (Hopefully Peter can correct me if I get any of these wrong.) - The patch uses a single database file and a new "-D" option to specify it on the command line. --> I think it might be less confusing to just put the database file(s) in the exports list and identify them via a ".db" filename suffix. What do others think? The changes are #ifdef'd on USE_SHAREDB. I'm thinking that this change will be always built, so maybe USE_SHAREDB is not needed? (Obviously mountd(8)'s semantics will only changed if/when database file(s) are provided.) Once I have feedback on the above, I will put a patch up on phabricator. rick ps: I believe kevans@ has volunteered to shepperd the ZFS share property changes. From nobody Fri Jul 21 05:36:51 2023 X-Original-To: fs@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 4R6dbR2GnQz4dQTS for ; Fri, 21 Jul 2023 05:36:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R6dbR1CsHz49qS for ; Fri, 21 Jul 2023 05:36:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689917811; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zzAR6yy9it4B00yyL8Flo4iqg57m7X/bIacYKdxI8Ww=; b=oj0jHhrVRWDgMuW9XHp1R1kmekYFdNLhbPwIb4eMkU1gQA4eG8eyQst+wQ7pWba+AWbvLi gE2FVDwjcehJGxPPw8LVOdatouUMwyHUve78t5kHcujohUS04Ed5qbRlCyBJCteawC4GFV VsT8RoFy3pP7hkN8yydXMZFjFiPJxANNRdle6PdKMjv7FIFoNuIktrhqxfbDmunPEVpVqP iI+Ker7oiWvU4TMMA1OPEsV1vQ5T4RoSad6YXofx8CR1bqHrdXr/IN91uz1kWMTWFrthL7 zxs295I/HlQ6sbjL3zmG50H395wa7+BOqHW3ap2WqpJCd954lS0ZFfUHB4di0w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689917811; a=rsa-sha256; cv=none; b=obcz8UvUK2NOsJIZ3BIioZ1ilCkb5nVsbO5GazRsYLEnQBcGtsIaUYPSK+uqR/r0UgLm5f TbBHeYL5lHzGEnyRHARR5j8yzymnpxovCBZIYsyq9tCV6gMpcDssPHiurVLzt12dsGfhjU 4py6V80ZdCYyN3uy2vIS8RzBaI27Zef1HrHCzhwRT2RKhrPbLjk28rzVLn8LcC97D/on1L fJtg8WrptjWZPOK0vjZAaf7kCrTUfxKSMsBX/p/iSIJKuMfE5M4nz8YeH5PW/qpuXOUy2U XnKngyoLAGBe9rErNoAjNKPgJuMOBLzQzGR/yJfXP7C9o3Z45gsIVTt3hRGPkQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4R6dbR0C7Pz11RT for ; Fri, 21 Jul 2023 05:36:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 36L5aoQg033269 for ; Fri, 21 Jul 2023 05:36:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 36L5aoiD033268 for fs@FreeBSD.org; Fri, 21 Jul 2023 05:36:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 272325] Page fault, possible ZFS related Date: Fri, 21 Jul 2023 05:36:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bsd@orsolic.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272325 --- Comment #4 from porsolic --- Another reproduction: Jul 21 03:01:00 zen-pobro root[98948]: [cron] daily Jul 21 03:04:40 zen-pobro syslogd: kernel boot file is /boot/kernel/kernel Jul 21 03:04:40 zen-pobro kernel: ---<>--- Jul 21 03:04:40 zen-pobro kernel: Copyright (c) 1992-2021 The FreeBSD Proje= ct. Jul 21 03:04:40 zen-pobro kernel: Copyright (c) 1979, 1980, 1983, 1986, 198= 8, 1989, 1991, 1992, 1993, 1994 Jul 21 03:04:40 zen-pobro kernel: The Regents of the University of California. All rights reserved. Jul 21 03:04:40 zen-pobro kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Fatal trap 12: page fault while in kernel mode cpuid =3D 6; apic id =3D 06 fault virtual address =3D 0x0 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff8286a65c stack pointer =3D 0x28:0xfffffe024f13a870 frame pointer =3D 0x28:0xfffffe024f13a930 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 99113 (zfs) trap number =3D 12 panic: page fault cpuid =3D 6 time =3D 1689901415 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Jul 21 05:37:13 2023 X-Original-To: fs@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 4R6dbs3h5Pz4dR5N for ; Fri, 21 Jul 2023 05:37:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R6dbs2cY0z4BP7 for ; Fri, 21 Jul 2023 05:37:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689917833; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MeU1BbsNsxicg4Rjybx7j8DX9A+Ep67u69S6CkRy3pQ=; b=YB8aEmAlaVHQo92gDjZaMOijZvydQUZ0JLn3pt0DUxQqHf1E1nJ1xg10slvY0wMuaitPjA mhneyFNQXKPuBjvGFXec6Eg3+6HztCPuv/8s7afWshjHebpc1uJmD+Nk1+g5N0e6NqYIOO d6yNbsMX6KOxtgA/bmYSTljVu/IZfwUG/3fhnIiXiVksOOjEzUdEDIqKsfZx21kXT3hte1 di4XOo2r5MChE24HLpkrbm5pyB96wv8zkrb/+vsMZQcEDoyH+Ob36ZnnwzQUPTtt2TkM+G m+pgYtegOTbYTr5+GG7MHWZf5eHKx4YWi8lbk02UFN0I++8N44Jvqz8KdJjpuA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689917833; a=rsa-sha256; cv=none; b=G2IQFtsleWrhMuHhVLBcAS4W37CC39JJ9MokRM8jnW82L7VR60tumNTHU8JFfCOZ6tCtfx EIMq0OyzjaDsF0CG8o/JdrYHX3QsTxIpQ6iGvt4PN4a5lqokv6iBP5MIceTAv6AAsNO7ct cwVKl1DB5A9EA0Hvso8owWec9xc/a2IW0Wfrf3fJbSetbYA+nkpulhiAWTInf/DXXFR7XU nTF830Hr8MgIUVk2+mp0swQCyfWII1Cy1vr6NRlz8638r44Zp6TSjlf+fPuKqWqKTi02pV SWFgrj7lgCXRWk/bGvV/I/ZPKtoOVEs5ZfPpWfHTFNLyJNKlNp7raoeWeL5yVQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4R6dbs1jjZz10sZ for ; Fri, 21 Jul 2023 05:37:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 36L5bD60033498 for ; Fri, 21 Jul 2023 05:37:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 36L5bDZ4033497 for fs@FreeBSD.org; Fri, 21 Jul 2023 05:37:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 272325] Page fault, possible ZFS related Date: Fri, 21 Jul 2023 05:37:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bsd@orsolic.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272325 --- Comment #5 from porsolic --- Created attachment 243515 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D243515&action= =3Dedit backtrace --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Jul 21 08:22:37 2023 X-Original-To: freebsd-fs@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 4R6jH04g5Fz4pCRT for ; Fri, 21 Jul 2023 08:22:52 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 4R6jGz4hC2z44Fr; Fri, 21 Jul 2023 08:22:51 +0000 (UTC) (envelope-from pen@lysator.liu.se) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of pen@lysator.liu.se designates 130.236.254.3 as permitted sender) smtp.mailfrom=pen@lysator.liu.se; dmarc=pass (policy=none) header.from=lysator.liu.se Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 80BCF1DCB0; Fri, 21 Jul 2023 10:22:48 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 7F42F1D9F8; Fri, 21 Jul 2023 10:22:48 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.6 X-Spam-Score: -1.0 Received: from smtpclient.apple (unknown [IPv6:2001:6b0:17:f002:1000::2f9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id F2DE21D943; Fri, 21 Jul 2023 10:22:47 +0200 (CEST) From: Peter Eriksson Message-Id: <2D8B626E-82BB-410C-B7C7-35B4D3834A44@lysator.liu.se> Content-Type: multipart/mixed; boundary="Apple-Mail=_723D3507-73DD-4B20-80BA-3FADE7093281" List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: RFC: Patch for mountd to handle a database for exports Date: Fri, 21 Jul 2023 10:22:37 +0200 In-Reply-To: Cc: kevans@freebsd.org, Rick Macklem To: FreeBSD FS References: X-Mailer: Apple Mail (2.3731.600.7) X-Virus-Scanned: ClamAV using ClamSMTP X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[lysator.liu.se,none]; RCVD_IN_DNSWL_MED(-0.20)[130.236.254.3:from]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; ASN(0.00)[asn:2843, ipnet:130.236.0.0/16, country:SE]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~,3:~,4:~,5:+]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; HAS_ATTACHMENT(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4R6jGz4hC2z44Fr X-Spamd-Bar: --- --Apple-Mail=_723D3507-73DD-4B20-80BA-3FADE7093281 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi! Here=E2=80=99s a couple of updated patches with some bug fixes. I=E2=80=99= ve also moved the database location for ZFS to /etc/zfs/exports.db to = mirror the current location. I also changed the patch for mountd so that for each =E2=80=9Cexports=E2=80= =9D source specified it first tries to open .db which I think = makes it easier to use (no need for the =E2=80=9C-D=E2=80=9D option and = it supports multiple sources). Cleaner I think. Btw, you can create the database manually from /etc/zfs/exports using = =E2=80=9Cmakemap=E2=80=9D like this: =20 makemap -f btree /etc/zfs/exports.db #include #include + +#define USE_SHAREDB 1 + +#ifdef USE_SHAREDB +#include +#include +#include +#endif + #include "pathnames.h" #include "mntopts.h" @@ -233,7 +242,7 @@ static void free_grp(struct grouplist *); static void free_host(struct hostlist *); static void free_v4rootexp(void); -static void get_exportlist_one(int); +static void get_exportlist_one(int, void *); static void get_exportlist(int); static void insert_exports(struct exportlist *, struct exportlisthead *); static void free_exports(struct exportlisthead *); @@ -1545,11 +1554,85 @@ static size_t linesize; static FILE *exp_file; +#ifdef USE_SHAREDB +static char *dat_path = NULL; +static char *dat_rest = NULL; +static DBT dat_k, dat_d; +static unsigned int dat_p = 0; + +static int +get_data(void *dbp) +{ + DB *sdb = (DB *) dbp; + int rc; + + + if (dat_path && dat_rest && dat_p < dat_d.size) { + /* Handle multiple share options per path */ + char *buf = (char *) dat_d.data; + int len; + + while (dat_p < dat_d.size && buf[dat_p] == '\0') + ++dat_p; + + len = strnlen(buf+dat_p, dat_d.size-dat_p); + if (len > 0) { + free(dat_rest); + dat_rest = strndup(buf+dat_p, len); + dat_p += len; + return 1; + } + } + + if (dat_path) { + free(dat_path); + dat_path = NULL; + } + if (dat_rest) { + free(dat_rest); + dat_rest = NULL; + } + + Again: + memset(&dat_k, 0, sizeof(dat_k)); + memset(&dat_d, 0, sizeof(dat_d)); + + rc = sdb->seq(sdb, &dat_k, &dat_d, R_NEXT); + switch (rc) { + case 0: + if (dat_k.size > 0 && ((char *) dat_k.data)[0] != '/') { + syslog(LOG_ERR, "%.*s: Invalid export path (ignored)", + (int) dat_k.size, (char *) dat_k.data); + goto Again; + } + + dat_path = strndup(dat_k.data, dat_k.size); + dat_rest = strndup(dat_d.data, dat_d.size); + dat_p = strlen(dat_rest); + return 1; + + case 1: + return 0; + + default: + syslog(LOG_ERR, "Error reading from sharedb: %s", strerror(errno)); + return -1; + } +} +#else +static int +get_data(void *dbp) { + return -1; +} + +#endif + /* * Get the export list from one, currently open file */ static void -get_exportlist_one(int passno) +get_exportlist_one(int passno, + void *db) { struct exportlist *ep; struct grouplist *grp, *tgrp, *savgrp; @@ -1563,14 +1646,16 @@ v4root_phase = 0; anon.cr_groups = NULL; dirhead = (struct dirlist *)NULL; - while (get_line()) { - if (debug) - warnx("got line %s", line); - cp = line; - nextfield(&cp, &endcp); - if (*cp == '#') - goto nextline; - + while ((db == NULL ? get_line() : get_data(db)) > 0) { + if (db == NULL) { + if (debug) + warnx("got line %s", line); + cp = line; + nextfield(&cp, &endcp); + if (*cp == '#') + goto nextline; + } + /* * Set defaults. */ @@ -1585,6 +1670,13 @@ ep = (struct exportlist *)NULL; dirp = NULL; +#if USE_SHAREDB + if (db) { + cp = dat_path; + len = strlen(dat_path); + endcp = dat_rest; + } else { +#endif /* * Handle the V4 root dir. */ @@ -1602,10 +1694,13 @@ nextfield(&cp, &endcp); } + len = endcp-cp; +#if USE_SHAREDB + } +#endif /* * Create new exports list entry */ - len = endcp-cp; tgrp = grp = get_grp(); while (len > 0) { if (len > MNTNAMLEN) { @@ -2103,13 +2198,31 @@ */ done = 0; for (i = 0; exnames[i] != NULL; i++) { +#if USE_SHAREDB + char dbpath[MAXPATHLEN]; + DB *sdb; + + snprintf(dbpath, sizeof(dbpath), "%s.db", exnames[i]); + sdb = dbopen(dbpath, O_RDONLY|O_SHLOCK, 0, DB_BTREE, NULL); + if (sdb) { + if (debug) + warnx("reading exports from DB %s", dbpath); + get_exportlist_one(passno, sdb); + sdb->close(sdb); + done++; + continue; + } + if (errno != ENOENT) + syslog(LOG_ERR, "%s: opening DB for reading: %s", + dbpath, strerror(errno)); +#endif if (debug) warnx("reading exports from %s", exnames[i]); if ((exp_file = fopen(exnames[i], "r")) == NULL) { syslog(LOG_WARNING, "can't open %s", exnames[i]); continue; } - get_exportlist_one(passno); + get_exportlist_one(passno, NULL); fclose(exp_file); done++; } --Apple-Mail=_723D3507-73DD-4B20-80BA-3FADE7093281 Content-Disposition: attachment; filename=libshare-nfs-sharedb.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="libshare-nfs-sharedb.patch" Content-Transfer-Encoding: 7bit --- sys/contrib/openzfs/lib/libshare/os/freebsd/nfs.c.ORIG 2023-07-19 23:46:53.058484000 +0200 +++ sys/contrib/openzfs/lib/libshare/os/freebsd/nfs.c 2023-07-20 17:01:15.349859000 +0200 @@ -53,6 +53,19 @@ #define ZFS_EXPORTS_FILE "/etc/zfs/exports" #define ZFS_EXPORTS_LOCK ZFS_EXPORTS_FILE".lock" +#define USE_SHAREDB 1 +#if USE_SHAREDB +#include +#include +#include +#include + +#define ZFS_SHAREDB_FILE "/etc/zfs/exports.db" + +static DB *sharedb = NULL; +static int sharedb_wrmode = 0; +#endif + static sa_fstype_t *nfs_fstype; static int nfs_lock_fd = -1; @@ -275,9 +288,45 @@ static int nfs_enable_share(sa_share_impl_t impl_share) { - char *filename = NULL; int error; + +#if USE_SHAREDB + DBT k, d; + int res; + char *shareopts = FSINFO(impl_share, nfs_fstype)->shareopts; + if (strcmp(shareopts, "on") == 0) + shareopts = ""; + + if (!sharedb || !sharedb_wrmode) { + if (sharedb) { + res = sharedb->close(sharedb); + if (res < 0) + fprintf(stderr, "nfs_enable_share: sharedb(\"%s\")->close: %s\n", ZFS_SHAREDB_FILE, strerror(errno)); + } + sharedb = dbopen(ZFS_SHAREDB_FILE, O_RDWR|O_CREAT|O_EXLOCK, 0600, DB_BTREE, NULL); + if (!sharedb) + fprintf(stderr, "nfs_enable_share: dbopen(\"%s\", O_RDWR|O_CREAT|O_EXLOCK): %s\n", ZFS_SHAREDB_FILE, strerror(errno)); + } + if (!sharedb) + return SA_SYSTEM_ERR; + + sharedb_wrmode = 1; + k.data = impl_share->sa_mountpoint; + k.size = strlen(k.data); + + d.data = translate_opts(shareopts); + d.size = strlen(d.data); + + res = sharedb->put(sharedb, &k, &d, 0); + if (res < 0) + fprintf(stderr, "nfs_enable_share: sharedb(\"%s\")->put(\"%s\"): %s\n", + ZFS_SHAREDB_FILE, (char *) k.data, strerror(errno)); + + return (res == 0 ? SA_OK : SA_SYSTEM_ERR); +#else + char *filename = NULL; + if ((filename = nfs_init_tmpfile()) == NULL) return (SA_SYSTEM_ERR); @@ -329,12 +378,41 @@ } error = nfs_fini_tmpfile(filename); nfs_exports_unlock(); +#endif return (error); } static int nfs_disable_share(sa_share_impl_t impl_share) { +#if USE_SHAREDB + DBT k; + int res; + + if (!sharedb || !sharedb_wrmode) { + if (sharedb) { + res = sharedb->close(sharedb); + if (res < 0) + fprintf(stderr, "nfs_disable_share: sharedb(\"%s\")->close: %s\n", ZFS_SHAREDB_FILE, strerror(errno)); + } + sharedb = dbopen(ZFS_SHAREDB_FILE, O_RDWR|O_CREAT|O_EXLOCK, 0600, DB_BTREE, NULL); + if (!sharedb) + fprintf(stderr, "nfs_disable_share: dbopen(\"%s\", O_RDWR|O_CREAT|O_EXLOCK): %s\n", ZFS_SHAREDB_FILE, strerror(errno)); + } + if (!sharedb) + return SA_SYSTEM_ERR; + + sharedb_wrmode = 1; + k.data = impl_share->sa_mountpoint; + k.size = strlen(k.data); + + res = sharedb->del(sharedb, &k, 0); + if (res < 0) + fprintf(stderr, "nfs_disable_share: sharedb(\"%s\")->del(\"%s\"): %s\n", + ZFS_SHAREDB_FILE, (char *) k.data, strerror(errno)); + + return (res == 0 ? SA_OK : SA_SYSTEM_ERR); +#else int error; char *filename = NULL; @@ -359,14 +437,39 @@ error = nfs_fini_tmpfile(filename); nfs_exports_unlock(); return (error); +#endif } static boolean_t nfs_is_shared(sa_share_impl_t impl_share) { +#if USE_SHAREDB + DBT k, d; + int res; + + if (!sharedb) { + sharedb = dbopen(ZFS_SHAREDB_FILE, O_RDONLY|O_SHLOCK, 0, DB_BTREE, NULL); + if (!sharedb && errno != ENOENT) { + fprintf(stderr, "dbopen(\"%s\", O_RDONLY|O_SHLOCK): %s\n", ZFS_SHAREDB_FILE, strerror(errno)); + } + } + if (!sharedb) + return (B_FALSE); + + k.data = impl_share->sa_mountpoint; + k.size = strlen(k.data); + + res = sharedb->get(sharedb, &k, &d, 0); + if (res < 0) + fprintf(stderr, "sharedb(\"%s\")->get(\"%s\"): %s\n", + ZFS_SHAREDB_FILE, (char *) k.data, strerror(errno)); + if (res == 0) + return (B_TRUE); + return (B_FALSE); +#else + char *mntpoint = impl_share->sa_mountpoint; char *s, last, line[MAXLINESIZE]; size_t len; - char *mntpoint = impl_share->sa_mountpoint; size_t mntlen = strlen(mntpoint); FILE *fp = fopen(ZFS_EXPORTS_FILE, "re"); @@ -393,6 +496,7 @@ } fclose(fp); return (B_FALSE); +#endif } static int @@ -422,13 +526,30 @@ { struct pidfh *pfh; pid_t mountdpid; + int res = SA_OK; -start: +#if USE_SHAREDB + if (sharedb) { + /* If ShareDB in use, close the database handle so any cached changes are flushed */ + + res = sharedb->close(sharedb); + if (res < 0) { + fprintf(stderr, "nfs_commit_shares: sharedb(\"%s\")->close: %s\n", + ZFS_SHAREDB_FILE, strerror(errno)); + res = SA_SYSTEM_ERR; + } + + sharedb = NULL; + sharedb_wrmode = 0; + } +#endif + + start: pfh = pidfile_open(_PATH_MOUNTDPID, 0600, &mountdpid); if (pfh != NULL) { /* mountd(8) is not running. */ pidfile_remove(pfh); - return (SA_OK); + return res; } if (errno != EEXIST) { /* Cannot open pidfile for some reason. */ @@ -441,7 +562,7 @@ } /* We have mountd(8) PID in mountdpid variable. */ kill(mountdpid, SIGHUP); - return (SA_OK); + return res; } static const sa_share_ops_t nfs_shareops = { --Apple-Mail=_723D3507-73DD-4B20-80BA-3FADE7093281 Content-Disposition: attachment; filename=share.c Content-Type: application/octet-stream; x-unix-mode=0644; name="share.c" Content-Transfer-Encoding: 7bit /* * share.c * * CLI utility to manipulate share DBs * * Version: 1.0.2 (2023-07-21) * * Copyright (c) 2023, Peter Eriksson * * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are met: * * 1. Redistributions of source code must retain the above copyright notice, this * list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright notice, * this list of conditions and the following disclaimer in the documentation * and/or other materials provided with the distribution. * * 3. Neither the name of the copyright holder nor the names of its * contributors may be used to endorse or promote products derived from * this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ /* * Compile with: cc -O -o share share.c * Usage: ./share -h * * ShareDB data format (B-Tree): * key = mountpoint (without trailing NUL characters) * data = mount options (per /etc/exports), multi-mountpoint options separated by NUL */ #include #include #include #include #include #include #include #include #include #include #include char *path_sharedb = "/etc/zfs/exports.db"; char *path_pidfile = "/var/run/mountd.pid"; int f_debug = 0; int f_print = 0; int f_signal = 0; int f_add = 0; int f_remove = 0; int f_locked = 1; void signal_mountd(void) { FILE *fp; int pid; if (!path_pidfile) return; fp = fopen(path_pidfile, "r"); if (!fp) return; if (fscanf(fp, "%u", &pid) == 1) kill(pid, SIGHUP); fclose(fp); } ssize_t scan_dbt(DBT *d, size_t size, char *opts) { char *buf = d->data; size_t p = 0; while (p < d->size) { int len = strnlen(buf+p, d->size-p); if (len == size && memcmp(opts, buf+p, len) == 0) return p; p += len; if (p < d->size && buf[p] == '\0') ++p; } return -1; } void print_dbt(DBT *d) { char *buf = d->data; size_t p = 0; int i = 0; while (p < d->size) { int len = strnlen(buf+p, d->size-p); printf("%2d : %.*s\n", i++, len, buf+p); p += len; if (p < d->size && buf[p] == '\0') ++p; } } int argv2dbt(int argc, char **argv, DBT *d) { char *buf; size_t len, newsize; int i, n; n = 0; len = 0; for (i = 0; i < argc; i++) { char *ap = argv[i]; int alen; /* Drop leading space */ while (isspace(*ap)) ++ap; /* Drop trailing space */ alen = strlen(ap); while (len > 0 && isspace(ap[alen-1])) --alen; if (!alen) continue; if (scan_dbt(d, alen, ap) >= 0) { printf("%s: Already in DBT\n", ap); continue; } if (d->data == NULL) { newsize = alen; d->data = malloc(newsize); buf = (char *) d->data; } else { newsize = d->size+1+alen; d->data = realloc(d->data, newsize); buf = (char *) d->data + d->size; *buf++ = '\0'; } d->size = newsize; strncpy(buf, ap, alen); buf += alen; } print_dbt(d); return n; } void print_data(size_t size, void *data) { unsigned char *buf = (unsigned char *) data; size_t pos = 0; for (pos = 0; pos < size; pos++) printf("%c ", isprint(buf[pos]) ? buf[pos] : '?'); putchar('\t'); for (pos = 0; pos < size; pos++) printf("%02x ", buf[pos]); putchar('\n'); } int main(int argc, char *argv[]) { DB *db; DBT k, d; int i, j, rc; char *buf; int f_mode = O_RDONLY; for (i = 1; i < argc && argv[i][0] == '-'; i++) { for (j = 1; argv[i][j]; j++) { switch (argv[i][j]) { case 'h': printf("Usage:\n\t%s [] [ [... ]]\n\n", argv[0]); puts("Options:"); puts("\t-h Display this usage information"); puts("\t-d Increase debugging level"); puts("\t-p Increase print level"); puts("\t-a Append options"); puts("\t-r Remove share / share options"); puts("\t-u Unlocked database access"); puts("\t-s Send signal to mountd"); puts("\t-D ShareDB path"); puts("\t-P Mountd pidfile path"); exit(0); case 'd': f_debug++; break; case 'u': f_locked = 0; break; case 'p': f_print++; break; case 'a': f_add++; break; case 'r': f_remove++; break; case 's': f_signal++; break; case 'D': if (argv[i][j+1]) path_sharedb = strdup(argv[i]+j+1); else if (i+1 < argc && argv[i+1][0]) path_sharedb = strdup(argv[++i]); else { fprintf(stderr, "%s: Error: Missing argument to -D\n", argv[0]); exit(1); } goto NextArg; case 'P': if (argv[i][j+1]) path_pidfile = strdup(argv[i]+j+1); else if (i+1 < argc && argv[i+1][0]) path_pidfile = strdup(argv[++i]); else { fprintf(stderr, "%s: Error: Missing argument to -P\n", argv[0]); exit(1); } goto NextArg; default: fprintf(stderr, "%s: Error: -%c: Invalid switch\n", argv[0], argv[i][j]); exit(1); } } NextArg:; } if (f_add || f_remove || i+1 < argc) { f_mode = O_RDWR; if (f_add || i+1 < argc) f_mode |= O_CREAT; if (f_locked) f_mode |= O_EXLOCK; } else if (f_locked) f_mode |= O_SHLOCK; while ((db = dbopen(path_sharedb, f_mode|O_NONBLOCK, 0600, DB_BTREE, NULL)) == NULL && errno == EWOULDBLOCK) { fprintf(stderr, "%s: Notice: %s: Database locked, retrying in 1s\n", argv[0], path_sharedb); sleep(1); } if (!db) { fprintf(stderr, "%s: Error: %s: Unable to open: %s\n", argv[0], path_sharedb, strerror(errno)); exit(1); } if (i < argc) { k.size = strlen(argv[i]); k.data = argv[i]; d.size = 0; d.data = NULL; if (f_remove) { if (i+1 == argc) { /* Delete the path */ rc = db->del(db, &k, 0); if (rc != 0) { fprintf(stderr, "%s: Error: %s: %s: DB delete failed: %s\n", argv[0], path_sharedb, argv[i], strerror(errno)); exit(1); } } else { /* Delete matching options */ fprintf(stderr, "%s: Error: Deleting matching options not yet implemented\n", argv[0]); exit(1); } } else { if (f_add) { /* Try to get existing entry, ignore if it doesn't exist */ if (db->get(db, &k, &d, 0) < 0) { fprintf(stderr, "%s: Error: %s: DB lookup failed: %s\n", argv[0], path_sharedb, strerror(errno)); exit(1); } if (d.size > 0) { buf = malloc(d.size); if (!buf) { fprintf(stderr, "%s: Error: %lu: malloc: %s\n", argv[0], d.size, strerror(errno)); exit(1); } memcpy(buf, d.data, d.size); d.data = buf; } if (argv2dbt(argc-i-1, argv+i+1, &d) < 0) { fprintf(stderr, "%s: Error: %s [%s]: Unable to extract options: %s\n", argv[0], argv[i], argv[i+1], strerror(errno)); exit(1); } rc = db->put(db, &k, &d, 0); if (rc != 0) { fprintf(stderr, "%s: Error: %s: %s: DB update failed: %s\n", argv[0], path_sharedb, argv[i], strerror(errno)); exit(1); } } else { /* Replace */ if (argv2dbt(argc-i-1, argv+i+1, &d) < 0) { fprintf(stderr, "%s: Error: %s [%s]: Unable to extract options: %s\n", argv[0], argv[i], argv[i+1], strerror(errno)); exit(1); } rc = db->put(db, &k, &d, 0); if (rc != 0) { fprintf(stderr, "%s: Error: %s: %s: DB update failed: %s\n", argv[0], path_sharedb, argv[i], strerror(errno)); exit(1); } } } if (d.data) free(d.data); } if (f_signal) signal_mountd(); if (f_print) { rc = db->seq(db, &k, &d, R_FIRST); while (rc == 0) { unsigned int p = 0; if (f_debug) { print_data(k.size, k.data); putchar('\n'); print_data(d.size, d.data); putchar('\n'); } for (p = 0; p < d.size; p++) { char *buf = (char *) d.data; int len = strnlen(buf+p, d.size-p); printf("%.*s\t%.*s\n", (int) k.size, (char *) k.data, len, buf+p); p += len; } rc = db->seq(db, &k, &d, R_NEXT); } } db->close(db); exit(0); } --Apple-Mail=_723D3507-73DD-4B20-80BA-3FADE7093281 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (I also agree that the USE_SHAREDB probably should be removed, I just = have that here for now so that I can quickly disable the code) Regarding the patch to the zfs part - I=E2=80=99m not sure which way to = go there - the current patch switches to always use the DB. But one = could argue that the code could check for an existing = /etc/zfs/exports.db and only use the DB-writing code if that already = exists. That way it will support both the old way and the new way, but = it requires an empty /etc/zfs/exports.db to be pre-created at initial = boot time for it to start using it.=20 - Peter > On 21 Jul 2023, at 00:50, Rick Macklem wrote: >=20 > Hi, >=20 > Peter Eriksson has submitted an interesting patch that adds support > for a database file for exports. My understanding is that this = improves > performance when used with the ZFS share property for exporting a > large number of file systems. >=20 > There are a couple of user visible issues that I'd like feedback from > others. (Hopefully Peter can correct me if I get any of these wrong.) >=20 > - The patch uses a single database file and a new "-D" option to > specify it on the command line. > --> I think it might be less confusing to just put the database = file(s) > in the exports list and identify them via a ".db" filename = suffix. > What do others think? >=20 > The changes are #ifdef'd on USE_SHAREDB. I'm thinking that this > change will be always built, so maybe USE_SHAREDB is not needed? > (Obviously mountd(8)'s semantics will only changed if/when database > file(s) are provided.) >=20 > Once I have feedback on the above, I will put a patch up on > phabricator. >=20 > rick > ps: I believe kevans@ has volunteered to shepperd the ZFS share > property changes. >=20 --Apple-Mail=_723D3507-73DD-4B20-80BA-3FADE7093281-- From nobody Fri Jul 21 08:37:12 2023 X-Original-To: freebsd-fs@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 4R6jbw6FRRz4pM81 for ; Fri, 21 Jul 2023 08:37:32 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (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 4R6jbv6pHJz47kW; Fri, 21 Jul 2023 08:37:31 +0000 (UTC) (envelope-from pen@lysator.liu.se) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of pen@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mailfrom=pen@lysator.liu.se; dmarc=pass (policy=none) header.from=lysator.liu.se Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id CD1621DC4A; Fri, 21 Jul 2023 10:37:23 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id CBB0B1DA5D; Fri, 21 Jul 2023 10:37:23 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.6 X-Spam-Score: -1.0 Received: from smtpclient.apple (unknown [IPv6:2001:6b0:17:f002:1000::2f9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 8C47D1DE84; Fri, 21 Jul 2023 10:37:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: RFC: Patch for mountd to handle a database for exports From: Peter Eriksson In-Reply-To: <2D8B626E-82BB-410C-B7C7-35B4D3834A44@lysator.liu.se> Date: Fri, 21 Jul 2023 10:37:12 +0200 Cc: kevans@freebsd.org, Rick Macklem Content-Transfer-Encoding: quoted-printable Message-Id: <7AC56987-BAB0-4291-8717-2D9EFB2487DB@lysator.liu.se> References: <2D8B626E-82BB-410C-B7C7-35B4D3834A44@lysator.liu.se> To: FreeBSD FS X-Mailer: Apple Mail (2.3731.600.7) X-Virus-Scanned: ClamAV using ClamSMTP X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[lysator.liu.se,none]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1653, ipnet:2001:6b0::/32, country:EU]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4R6jbv6pHJz47kW X-Spamd-Bar: --- Regarding the potential for speed improvement here is a quick little = benchmark=E2=80=A6 > # wc -l /etc/zfs/exports > 13116 /etc/zfs/exports With the original FreeBSD 13.2 code: > # /usr/bin/time zfs share -a > 40.08 real 34.00 user 6.04 sys > # /usr/bin/time zfs share -a > 40.15 real 34.06 user 6.04 sys With the DB code in use: > # service mountd stop ; mv /usr/sbin/mountd.DB /usr/sbin/mountd ; mv = /lib/libzfs.so.4.DB /lib/libzfs.so.4 > # rm -f /etc/zfs/exports.db > # /usr/bin/time zfs share -a > 2.75 real 0.88 user 1.87 sys > # /usr/bin/time zfs share -a > 2.77 real 1.01 user 1.75 sys This translates into a shorter boot time if nothing else... - Peter > On 21 Jul 2023, at 10:22, Peter Eriksson wrote: >=20 > Hi! >=20 > Here=E2=80=99s a couple of updated patches with some bug fixes. I=E2=80=99= ve also moved the database location for ZFS to /etc/zfs/exports.db to = mirror the current location. >=20 > I also changed the patch for mountd so that for each =E2=80=9Cexports=E2= =80=9D source specified it first tries to open .db which I think = makes it easier to use (no need for the =E2=80=9C-D=E2=80=9D option and = it supports multiple sources). Cleaner I think. >=20 >=20 > Btw, you can create the database manually from /etc/zfs/exports using = =E2=80=9Cmakemap=E2=80=9D like this: >=20 > makemap -f btree /etc/zfs/exports.db =20 >=20 > Known =E2=80=9Cbugs=E2=80=9D: > =E2=80=9CV4:=E2=80=9D=20 > Even though you could create an /etc/exports.db with the contents of = /etc/exports it will fail with the =E2=80=9CV4:=E2=80=9D lines since the = BTree database will sort the exported entries so that the V4: key will = appear last and then mountd will complain when scanning the DB.=20 >=20 > Also when using the file /etc/exports you can either write = =E2=80=9CV4:/export -sec=3Dsys=E2=80=9D or =E2=80=9CV4: /export = -sec=3Dsys=E2=80=9D (with a space between V4: and the path) so this = probably needs some special handling (can=E2=80=99t simply use = =E2=80=9Cmakemap -f btree /etc/exports.db =20 > I did try to fix that but the code quickly got hairy so I didn=E2=80=99t= like it. If we really want/need that I=E2=80=99m thinking of creating a = special case for the V4: handling, sort of like prefixing the database = key with a NUL byte or something (so that it will be sorted first).=20 >=20 >=20 > Multiline options - well, the current ZFS code doesn=E2=80=99t support = it either so no change from the current setup but it would be nice to = have. > Ie, support for things like: > /export -sec=3Dkrb5 > /export -sec=3Dsys ro >=20 >=20 >=20 > >=20 >=20 > (I also agree that the USE_SHAREDB probably should be removed, I just = have that here for now so that I can quickly disable the code) >=20 > Regarding the patch to the zfs part - I=E2=80=99m not sure which way = to go there - the current patch switches to always use the DB. But one = could argue that the code could check for an existing = /etc/zfs/exports.db and only use the DB-writing code if that already = exists. That way it will support both the old way and the new way, but = it requires an empty /etc/zfs/exports.db to be pre-created at initial = boot time for it to start using it.=20 >=20 > - Peter >=20 >=20 >> On 21 Jul 2023, at 00:50, Rick Macklem = wrote: >>=20 >> Hi, >>=20 >> Peter Eriksson has submitted an interesting patch that adds support >> for a database file for exports. My understanding is that this = improves >> performance when used with the ZFS share property for exporting a >> large number of file systems. >>=20 >> There are a couple of user visible issues that I'd like feedback from >> others. (Hopefully Peter can correct me if I get any of these wrong.) >>=20 >> - The patch uses a single database file and a new "-D" option to >> specify it on the command line. >> --> I think it might be less confusing to just put the database = file(s) >> in the exports list and identify them via a ".db" filename = suffix. >> What do others think? >>=20 >> The changes are #ifdef'd on USE_SHAREDB. I'm thinking that this >> change will be always built, so maybe USE_SHAREDB is not needed? >> (Obviously mountd(8)'s semantics will only changed if/when database >> file(s) are provided.) >>=20 >> Once I have feedback on the above, I will put a patch up on >> phabricator. >>=20 >> rick >> ps: I believe kevans@ has volunteered to shepperd the ZFS share >> property changes. >>=20 >=20 From nobody Fri Jul 21 15:07:50 2023 X-Original-To: freebsd-fs@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 4R6tGT17c2z4nmxp for ; Fri, 21 Jul 2023 15:08:01 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R6tGT0jzwz4Bsj; Fri, 21 Jul 2023 15:08:01 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x130.google.com with SMTP id e9e14a558f8ab-3487d75e4c5so9883325ab.0; Fri, 21 Jul 2023 08:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689952080; x=1690556880; 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=QMM/Aa0c948dY/ZuAvbEAUygJAwkU5mlEljIb/7Dfq4=; b=XW+TN50FbesK2qu32MeJCFidv2aql3eCcxEZv9siGCgqdbo/N3wO20G2/LlI7tKno5 IxuC+yVcM2BENtKxE7ZhPDMcBBT+nD2N1i7oTaAwr0WaLIxDuecJJfw5mkbKdBEpMzd5 Q1R76aoZFpQzJFnFvEHT9S6Hpg3qevZz3hJQM7bpjssO5hlECkcKZjVuuSB8bt2Lndzt AyMiZ+qbTw/YnsHK1oft+6sZA08MRwH2kKofMDd3jpbAcXrCwkInNVm7cBnHmHSjp+Ay 9gCZhuIIZybS/EX84sp6HkLKFZ4w12tZq3YMN1IfpmSYL7XJfhpVHZsuVkJg2W83qULD dZlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689952080; x=1690556880; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QMM/Aa0c948dY/ZuAvbEAUygJAwkU5mlEljIb/7Dfq4=; b=YyViSPUxKd7SLxzeN9J4ItmpJpEG6hlIjKXHlbBvVwd+LELKzVsuRqz0pgUw0oP8Ec i/PYAc80cCpSj/Xjc6YpUfXd/aHtibnlHFUfbnrCykqmwYRifGmY+ksoNEdJxWaM4X+j dnoPSSVm/bqBmmHRY4Z9Sjk4rkKTkh2gpS6Z3Td1bj7IgVCPsGGumxh5yNr/P4m3wyM+ mnAxYP9GuOYkfvqsDVTB5VSad4CMQ7BlsT49JOPws97D5dZImkqdqO48yW4tzCBLGO1z JOVeTw+mYNUKhBMXSXHay2Lt+2Bodqlb/ffzV0rwajftnXXm/5xodQElqCjC5sqGH0HH 6feA== X-Gm-Message-State: ABy/qLYJDJKb7oy0jNmN1vUFAjE1K4voRKIX2+kuWkQZesI3QflK5OIh +H6Dsh7p9O6YN9hSdTZLMLSSgQ+NuivBewFyXld2of7SaA== X-Google-Smtp-Source: APBJJlFatlMKcKm66XtaXACskmUHcRYgAP1EzHEDU+0yEirKkB2YaSsJBADOVUMDTPfNJDnqLfzg18bCeYAGAKE5uRs= X-Received: by 2002:a05:6e02:1062:b0:346:5249:9ae1 with SMTP id q2-20020a056e02106200b0034652499ae1mr231472ilj.12.1689952080277; Fri, 21 Jul 2023 08:08:00 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: <2D8B626E-82BB-410C-B7C7-35B4D3834A44@lysator.liu.se> In-Reply-To: <2D8B626E-82BB-410C-B7C7-35B4D3834A44@lysator.liu.se> From: Rick Macklem Date: Fri, 21 Jul 2023 08:07:50 -0700 Message-ID: Subject: Re: RFC: Patch for mountd to handle a database for exports To: Peter Eriksson Cc: FreeBSD FS , kevans@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4R6tGT0jzwz4Bsj 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]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Fri, Jul 21, 2023 at 1:22=E2=80=AFAM Peter Eriksson = wrote: > > Hi! > > Here=E2=80=99s a couple of updated patches with some bug fixes. I=E2=80= =99ve also moved the database location for ZFS to /etc/zfs/exports.db to mi= rror the current location. > > I also changed the patch for mountd so that for each =E2=80=9Cexports=E2= =80=9D source specified it first tries to open .db which I think make= s it easier to use (no need for the =E2=80=9C-D=E2=80=9D option and it supp= orts multiple sources). Cleaner I think. > > > Btw, you can create the database manually from /etc/zfs/exports using =E2= =80=9Cmakemap=E2=80=9D like this: > > makemap -f btree /etc/zfs/exports.db > > Known =E2=80=9Cbugs=E2=80=9D: > =E2=80=9CV4:=E2=80=9D > Even though you could create an /etc/exports.db with the contents of /etc= /exports it will fail with the =E2=80=9CV4:=E2=80=9D lines since the BTree = database will sort the exported entries so that the V4: key will appear las= t and then mountd will complain when scanning the DB. > > Also when using the file /etc/exports you can either write =E2=80=9CV4:/e= xport -sec=3Dsys=E2=80=9D or =E2=80=9CV4: /export -sec=3Dsys=E2=80=9D (with= a space between V4: and the path) so this probably needs some special hand= ling (can=E2=80=99t simply use =E2=80=9Cmakemap -f btree /etc/exports.db > I did try to fix that but the code quickly got hairy so I didn=E2=80=99t = like it. If we really want/need that I=E2=80=99m thinking of creating a spe= cial case for the V4: handling, sort of like prefixing the database key wit= h a NUL byte or something (so that it will be sorted first). > Does the ZFS share property generate a V4: line? I doubt anyone will convert a non-ZFS /etc/exports file to a DB file, so support of that does not seem to be needed. I see this as useful for the ZFS share property case, so if that works correctly, I do not see the above as a concern. > > Multiline options - well, the current ZFS code doesn=E2=80=99t support it= either so no change from the current setup but it would be nice to have. > Ie, support for things like: > /export -sec=3Dkrb5 > /export -sec=3Dsys ro > Yes. There is at least one PR that requests that the ZFS share property be enhanced to do this. Part of the reason for getting this patch in main is so that this can be pursued. Again, I only see this as a ZFS share property issue because I do not see any reason to convert /etc/exports flat files to db files? rick > > > > > > (I also agree that the USE_SHAREDB probably should be removed, I just hav= e that here for now so that I can quickly disable the code) > > Regarding the patch to the zfs part - I=E2=80=99m not sure which way to g= o there - the current patch switches to always use the DB. But one could ar= gue that the code could check for an existing /etc/zfs/exports.db and only = use the DB-writing code if that already exists. That way it will support bo= th the old way and the new way, but it requires an empty /etc/zfs/exports.d= b to be pre-created at initial boot time for it to start using it. > > - Peter > > > > On 21 Jul 2023, at 00:50, Rick Macklem wrote: > > > > Hi, > > > > Peter Eriksson has submitted an interesting patch that adds support > > for a database file for exports. My understanding is that this improve= s > > performance when used with the ZFS share property for exporting a > > large number of file systems. > > > > There are a couple of user visible issues that I'd like feedback from > > others. (Hopefully Peter can correct me if I get any of these wrong.) > > > > - The patch uses a single database file and a new "-D" option to > > specify it on the command line. > > --> I think it might be less confusing to just put the database file(s= ) > > in the exports list and identify them via a ".db" filename suffi= x. > > What do others think? > > > > The changes are #ifdef'd on USE_SHAREDB. I'm thinking that this > > change will be always built, so maybe USE_SHAREDB is not needed? > > (Obviously mountd(8)'s semantics will only changed if/when database > > file(s) are provided.) > > > > Once I have feedback on the above, I will put a patch up on > > phabricator. > > > > rick > > ps: I believe kevans@ has volunteered to shepperd the ZFS share > > property changes. > > > From nobody Fri Jul 21 20:33:17 2023 X-Original-To: freebsd-fs@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 4R71V54vRVz4nnbK for ; Fri, 21 Jul 2023 20:33:33 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 4R71V43ttxz3jkv; Fri, 21 Jul 2023 20:33:32 +0000 (UTC) (envelope-from pen@lysator.liu.se) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of pen@lysator.liu.se designates 130.236.254.3 as permitted sender) smtp.mailfrom=pen@lysator.liu.se; dmarc=pass (policy=none) header.from=lysator.liu.se Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 1453F1EB67; Fri, 21 Jul 2023 22:33:30 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id F2EEA1EBF2; Fri, 21 Jul 2023 22:33:29 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,AWL,HTML_MESSAGE, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.6 X-Spam-Score: -1.0 Received: from smtpclient.apple (unknown [IPv6:2001:9b1:28fa:7900:1db5:1a62:7f0f:4ba]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id EE43C1EBF1; Fri, 21 Jul 2023 22:33:28 +0200 (CEST) From: Peter Eriksson Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F528DA9E-C185-410F-9675-2F557F67BE84" List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: RFC: Patch for mountd to handle a database for exports Date: Fri, 21 Jul 2023 22:33:17 +0200 In-Reply-To: Cc: kevans@freebsd.org, Rick Macklem To: FreeBSD FS References: <2D8B626E-82BB-410C-B7C7-35B4D3834A44@lysator.liu.se> X-Mailer: Apple Mail (2.3731.600.7) X-Virus-Scanned: ClamAV using ClamSMTP X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.985]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[lysator.liu.se,none]; RCVD_IN_DNSWL_MED(-0.20)[130.236.254.3:from]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:2843, ipnet:130.236.0.0/16, country:SE]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4R71V43ttxz3jkv X-Spamd-Bar: --- --Apple-Mail=_F528DA9E-C185-410F-9675-2F557F67BE84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> I did try to fix that but the code quickly got hairy so I didn=E2=80=99= t like it. If we really want/need that I=E2=80=99m thinking of creating = a special case for the V4: handling, sort of like prefixing the database = key with a NUL byte or something (so that it will be sorted first). >>=20 > Does the ZFS share property generate a V4: line? > I doubt anyone will convert a non-ZFS /etc/exports file to a DB file, > so support of that does not seem to be needed. >=20 > I see this as useful for the ZFS share property case, > so if that works correctly, I do not see the above as a concern. No, the ZFS share property stuff never generates the V4: line(s) so = it=E2=80=99s not a problem for the /etc/zfs/exports.db case. And converting /etc/exports to /etc/exports.db is not really necessary = from a performance point since I doubt it ever will be very long.=20 However I bet some enthusiastic fellow is bound to try to do it sometime = in the future just because it can be done :-) >>=20 >> Multiline options - well, the current ZFS code doesn=E2=80=99t = support it either so no change from the current setup but it would be = nice to have. >> Ie, support for things like: >> /export -sec=3Dkrb5 >> /export -sec=3Dsys ro >>=20 > Yes. There is at least one PR that requests that the ZFS share = property > be enhanced to do this. Part of the reason for getting this patch in = main > is so that this can be pursued. >=20 > Again, I only see this as a ZFS share property issue because I do not > see any reason to convert /etc/exports flat files to db files? >=20 I agree that the need probably isn=E2=80=99t there. The current DB code will generate a syslog(LOG_ERR) warning if it = detects anything not starting with / in the keys (and ignores it). Perhaps there should be a warning in the manual for mountd about not = trying to convert /etc/exports into a DB (if it uses NFSv4 / the = =E2=80=9CV4:=E2=80=9D line(s)).=20 Or should we just special-case /etc/exports and forbid the check for = /etc/exports.db?=20 - Peter > rick >=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> (I also agree that the USE_SHAREDB probably should be removed, I just = have that here for now so that I can quickly disable the code) >>=20 >> Regarding the patch to the zfs part - I=E2=80=99m not sure which way = to go there - the current patch switches to always use the DB. But one = could argue that the code could check for an existing = /etc/zfs/exports.db and only use the DB-writing code if that already = exists. That way it will support both the old way and the new way, but = it requires an empty /etc/zfs/exports.db to be pre-created at initial = boot time for it to start using it. >>=20 >> - Peter >>=20 >>=20 >>> On 21 Jul 2023, at 00:50, Rick Macklem = wrote: >>>=20 >>> Hi, >>>=20 >>> Peter Eriksson has submitted an interesting patch that adds support >>> for a database file for exports. My understanding is that this = improves >>> performance when used with the ZFS share property for exporting a >>> large number of file systems. >>>=20 >>> There are a couple of user visible issues that I'd like feedback = from >>> others. (Hopefully Peter can correct me if I get any of these = wrong.) >>>=20 >>> - The patch uses a single database file and a new "-D" option to >>> specify it on the command line. >>> --> I think it might be less confusing to just put the database = file(s) >>> in the exports list and identify them via a ".db" filename = suffix. >>> What do others think? >>>=20 >>> The changes are #ifdef'd on USE_SHAREDB. I'm thinking that this >>> change will be always built, so maybe USE_SHAREDB is not needed? >>> (Obviously mountd(8)'s semantics will only changed if/when database >>> file(s) are provided.) >>>=20 >>> Once I have feedback on the above, I will put a patch up on >>> phabricator. >>>=20 >>> rick >>> ps: I believe kevans@ has volunteered to shepperd the ZFS share >>> property changes. --Apple-Mail=_F528DA9E-C185-410F-9675-2F557F67BE84 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I did try to fix that but the code quickly got hairy so I = didn=E2=80=99t like it. If we really want/need that I=E2=80=99m thinking = of creating a special case for the V4: handling, sort of like prefixing = the database key with a NUL byte or something (so that it will be sorted = first).

Does = the ZFS share property generate a V4: line?
I doubt anyone will convert a non-ZFS = /etc/exports file to a DB file,
so = support of that does not seem to be needed.

I see this as useful for the ZFS share = property case,
so if = that works correctly, I do not see the above as a concern.

No, the ZFS share property = stuff never generates the V4: line(s) so it=E2=80=99s not a problem for = the /etc/zfs/exports.db case.

And converting = /etc/exports to /etc/exports.db is not really necessary from a = performance point since I doubt it ever will be very = long. 
However I bet some enthusiastic fellow is bound to = try to do it sometime in the future just because it can be done = :-)



Multiline options - well, the current ZFS code doesn=E2=80=99t = support it either so no change from the current setup but it would be = nice to have.
 Ie, support for things = like:
    /export = -sec=3Dkrb5
    /export -sec=3Dsys = ro

Yes. = There is at least one PR that requests that the ZFS share = property
be enhanced to do this. = Part of the reason for getting this patch in main
is so that this can be pursued.

Again, I only see this as a ZFS share = property issue because I do not
see any = reason to convert /etc/exports flat files to db files?


I agree that the need probably = isn=E2=80=99t there.

The current DB code will = generate a syslog(LOG_ERR) warning if it detects anything not starting = with / in the keys (and ignores it).

Perhaps = there should be a warning in the manual for mountd about not trying to = convert /etc/exports into a DB (if it uses NFSv4 / the =E2=80=9CV4:=E2=80=9D= line(s)). 
Or should we just special-case /etc/exports = and forbid the check for = /etc/exports.db? 

- = Peter

rick






(I also agree that the = USE_SHAREDB probably should be removed, I just have that here for now so = that I can quickly disable the code)

Regarding the patch to the = zfs part - I=E2=80=99m not sure which way to go there - the current = patch switches to always use the DB. But one could argue that the code = could check for an existing /etc/zfs/exports.db and only use the = DB-writing code if that already exists. That way it will support both = the old way and the new way, but it requires an empty = /etc/zfs/exports.db to be pre-created at initial boot time for it to = start using it.

- Peter


On = 21 Jul 2023, at 00:50, Rick Macklem <rick.macklem@gmail.com> = wrote:

Hi,

Peter Eriksson has submitted an interesting = patch that adds support
for a database file for exports.  My = understanding is that this improves
performance when used with the = ZFS share property for exporting a
large number of file = systems.

There are a couple of user visible issues that I'd like = feedback from
others. (Hopefully Peter can correct me if I get any of = these wrong.)

- The patch uses a single database file and a new = "-D" option to
specify it on the command line.
--> I think it = might be less confusing to just put the database = file(s)
      in the exports list and = identify them via a ".db" filename suffix.
What do others = think?

The changes are #ifdef'd on USE_SHAREDB. I'm thinking that = this
change will be always built, so maybe USE_SHAREDB is not = needed?
(Obviously mountd(8)'s semantics will only changed if/when = database
file(s) are provided.)

Once I have feedback on the = above, I will put a patch up on
phabricator.

rick
ps: I = believe kevans@ has volunteered to shepperd the ZFS = share
    property = changes.

= --Apple-Mail=_F528DA9E-C185-410F-9675-2F557F67BE84-- From nobody Fri Jul 21 23:07:26 2023 X-Original-To: freebsd-fs@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 4R74vs6CPqz4pSC2 for ; Fri, 21 Jul 2023 23:07:37 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R74vs4Vr9z3Dg3; Fri, 21 Jul 2023 23:07:37 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-26586e824e7so1251759a91.3; Fri, 21 Jul 2023 16:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689980856; x=1690585656; 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=pp/Kh3Jfb3VnnQqtUH2jAX+mSUfDrhbTVRCtZ3c9WQM=; b=RSfrnr0ucv1CvOl71hx+x3ao+HAPWfJf83BK5a23LsGRFtcTOWQksWagzQTvqVa8U1 Ix8n5ftWKpLKTISV1pIKGEwl1t7RxV2HFUp8dfWX14yyHflZb4wQgIUyASicwBJlhiiv krrh3E2uB7XYYj2JA1lRQI66U8R8BNfQeMURVKsX3kznZSDCQtR8OxpgRQokYgRuD0jk 7vnNQycpiNaAzVrciIBR/IymGCqXsUVvxIglsYa4xTm5M9q9tjgkQ7Pfa88YFbLqPFuH Kl0x6Zz2AHsTeazFJYAoextc3aUh6BhP/Sex0oLhAsKNgbNlf6IODCLKX+6t8pJ5XSoW Nl3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689980856; x=1690585656; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pp/Kh3Jfb3VnnQqtUH2jAX+mSUfDrhbTVRCtZ3c9WQM=; b=k/VbDl/Roly2vL1chjP0Wp9Lw2fgJwiHOpubktpHGMjOsr+SUDSzjC7dfg7b3K8pq8 uQOBc6r/tpJmjlm8NwSMMlbrC3dbZueVWSGPEVEVtK21Du0E30pgj6aslm/4H2ZEVgr/ vgD07k4E5xtpKU7SDlsuNBjBURetE1XrI8U6SJb9XieYrv3tCoG1lxEksSOOzcxbxqsZ Dj0JsNIUyLDCR6w+j/mJwmbUMJBcTEZtSzbaxmhOJ7rTPAE3Qu6Rqf87WD4gF/ywOier vx6VwzkeD9826r7BjPr8UXyV0E3ypn0BZ6Mx5yy1gvMN8rCIQdTheSSu94DX9eQ/zFjF 8zMQ== X-Gm-Message-State: ABy/qLZMVmG3gZ5Rj/t417F5AU+AakkfTI99iyiz54jPnoMO13bIXeJi kCgD6UkmIGWEXjejloZYIYUiGeVn3SgNCLu0sQ== X-Google-Smtp-Source: APBJJlGmD34KG3iqyuYoaz+A7MfjYVPhprR4p15bb/zy6ZiI7LJwmdOzvyZc07UAVqdXz4ZXk2G3ZfjXgRPg19vlXuY= X-Received: by 2002:a17:90a:c254:b0:263:72d2:18dd with SMTP id d20-20020a17090ac25400b0026372d218ddmr2308647pjx.3.1689980856035; Fri, 21 Jul 2023 16:07:36 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: <2D8B626E-82BB-410C-B7C7-35B4D3834A44@lysator.liu.se> In-Reply-To: From: Rick Macklem Date: Fri, 21 Jul 2023 16:07:26 -0700 Message-ID: Subject: Re: RFC: Patch for mountd to handle a database for exports To: Peter Eriksson Cc: FreeBSD FS , kevans@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4R74vs4Vr9z3Dg3 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]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Fri, Jul 21, 2023 at 1:33=E2=80=AFPM Peter Eriksson = wrote: > > > I did try to fix that but the code quickly got hairy so I didn=E2=80=99t = like it. If we really want/need that I=E2=80=99m thinking of creating a spe= cial case for the V4: handling, sort of like prefixing the database key wit= h a NUL byte or something (so that it will be sorted first). > > Does the ZFS share property generate a V4: line? > I doubt anyone will convert a non-ZFS /etc/exports file to a DB file, > so support of that does not seem to be needed. > > I see this as useful for the ZFS share property case, > so if that works correctly, I do not see the above as a concern. > > > No, the ZFS share property stuff never generates the V4: line(s) so it=E2= =80=99s not a problem for the /etc/zfs/exports.db case. > > And converting /etc/exports to /etc/exports.db is not really necessary fr= om a performance point since I doubt it ever will be very long. > However I bet some enthusiastic fellow is bound to try to do it sometime = in the future just because it can be done :-) > Yep. Capturing this in a man page update when the time comes needs to be done, I think? (That the V4: line doesn't work in the DB.) > > > Multiline options - well, the current ZFS code doesn=E2=80=99t support it= either so no change from the current setup but it would be nice to have. > Ie, support for things like: > /export -sec=3Dkrb5 > /export -sec=3Dsys ro > > Yes. There is at least one PR that requests that the ZFS share property > be enhanced to do this. Part of the reason for getting this patch in main > is so that this can be pursued. > > Again, I only see this as a ZFS share property issue because I do not > see any reason to convert /etc/exports flat files to db files? > > > I agree that the need probably isn=E2=80=99t there. > > The current DB code will generate a syslog(LOG_ERR) warning if it detects= anything not starting with / in the keys (and ignores it). > > Perhaps there should be a warning in the manual for mountd about not tryi= ng to convert /etc/exports into a DB (if it uses NFSv4 / the =E2=80=9CV4:= =E2=80=9D line(s)). > Or should we just special-case /etc/exports and forbid the check for /etc= /exports.db? > > - Peter > > rick > > > > > > > (I also agree that the USE_SHAREDB probably should be removed, I just hav= e that here for now so that I can quickly disable the code) > > Regarding the patch to the zfs part - I=E2=80=99m not sure which way to g= o there - the current patch switches to always use the DB. But one could ar= gue that the code could check for an existing /etc/zfs/exports.db and only = use the DB-writing code if that already exists. That way it will support bo= th the old way and the new way, but it requires an empty /etc/zfs/exports.d= b to be pre-created at initial boot time for it to start using it. That's up to the ZFS folk. Hopefully kevans@ can figure it out. rick > > - Peter > > > On 21 Jul 2023, at 00:50, Rick Macklem wrote: > > Hi, > > Peter Eriksson has submitted an interesting patch that adds support > for a database file for exports. My understanding is that this improves > performance when used with the ZFS share property for exporting a > large number of file systems. > > There are a couple of user visible issues that I'd like feedback from > others. (Hopefully Peter can correct me if I get any of these wrong.) > > - The patch uses a single database file and a new "-D" option to > specify it on the command line. > --> I think it might be less confusing to just put the database file(s) > in the exports list and identify them via a ".db" filename suffix. > What do others think? > > The changes are #ifdef'd on USE_SHAREDB. I'm thinking that this > change will be always built, so maybe USE_SHAREDB is not needed? > (Obviously mountd(8)'s semantics will only changed if/when database > file(s) are provided.) > > Once I have feedback on the above, I will put a patch up on > phabricator. > > rick > ps: I believe kevans@ has volunteered to shepperd the ZFS share > property changes. > > From nobody Sat Jul 22 03:50:42 2023 X-Original-To: freebsd-fs@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 4R7CBY2JMbz4p260 for ; Sat, 22 Jul 2023 03:50:45 +0000 (UTC) (envelope-from kevans@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R7CBY1bncz3NWg; Sat, 22 Jul 2023 03:50:45 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689997845; 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=QwEZn38aWA1ZYngcmgILZXVZkb1Kj7EbHp23sXsXqRU=; b=ur4F5AVVK/sXqQ25/BlrK272nisD9BvFgLb+vCZvGXwf7+zM8LTackw6YaU5R7dWpub3oq jR2h1QfgXrpk1Hl7i0jkNF3cG50F+AKdsmwXOQbyG9xEEzMHns85vhmius3VYmObEbiLfG dATkAR+8N7JBqVHvgjN0syVmQpijxroRDVos+4/zSDnMKhSkG7Iqfv//lr5Kgiw9IHmAOl En/WPqq6fQ9XHqxsat/j+ZKC6dBR8KMxD34L5a1DW7lMgPqT2O8eRCADs9lgfTndLT1SKK uxMc6RxvtwzsjlojWLb67C1N9mOGxHaLW2se+5NwF4urc/Rr2yIALTO1QuBUkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689997845; 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=QwEZn38aWA1ZYngcmgILZXVZkb1Kj7EbHp23sXsXqRU=; b=Pxj32EgTScm6qo1YQWVAgfnEkFYJ8Rdhc1X1H2owUHYkWhaGHSgajbdIPBy4ElDwAO8wir MALAo0YKZ/6i1W7kRo9OWiyJmfKjHWtDNp0Befxs0t1dS7JrozpfSGW1ll8Zp5urrCb6n8 U5XpV9D+fFfAEGWVb/KOaCKXQSipkkiHEHoWHMounTk0r8PmhV+nT4MoKCktvFQ6PS9lYx efdcsLQ34EmQa1zs5QZa7amsjwg3kdEixPPDhLb85yAuYcOp+I/Cw1zp6LRS+knynghB/T Cn2AVhE8FajCnvW0mNfrx1PcxlnpNYDeWd5YaLlTOVKFY5Opmpyxgfc9FOrGjw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689997845; a=rsa-sha256; cv=none; b=LcDSYUSQ0KgPsyw05OljMRpwTXxuj3YCqaM5+GAnGolFGe+9JEnY/HO/BaydGqieW+OTEo 4aCnmS9BBFzhUZeiI0tnxQWGUxMr/QXP7A6JKSU5fS2WdLBk7ewQ5d1XPJ0Ns1e2XI/Wjs urF9qdwCWvGCZIBINLjVYK8my8nOmoiKIVwFCpyUN4GA5/oWDABcmptFzpXbEQ9gZXuSyw L9Wovm7kmVnCyZcwOB+SIZf5GfvzKYfUAFdH98RLFBitaokaL3wgyJe3vgTzLM4t/RwQn1 0GXdJBI6I6DNSu27eDp/VzuM/OIts2BtXfq0DjYBm95VEbtA/bI7pgjluH9QyA== Received: from [10.9.4.95] (unknown [209.182.120.176]) (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) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4R7CBX5mmVzGw0; Sat, 22 Jul 2023 03:50:44 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <19330773-51dd-d3ed-5cff-c4a139b130ee@FreeBSD.org> Date: Fri, 21 Jul 2023 22:50:42 -0500 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: RFC: Patch for mountd to handle a database for exports Content-Language: en-US To: Rick Macklem , Peter Eriksson Cc: FreeBSD FS References: <2D8B626E-82BB-410C-B7C7-35B4D3834A44@lysator.liu.se> From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/21/23 18:07, Rick Macklem wrote: > On Fri, Jul 21, 2023 at 1:33 PM Peter Eriksson wrote: >> >> >> I did try to fix that but the code quickly got hairy so I didn’t like it. If we really want/need that I’m thinking of creating a special case for the V4: handling, sort of like prefixing the database key with a NUL byte or something (so that it will be sorted first). >> >> Does the ZFS share property generate a V4: line? >> I doubt anyone will convert a non-ZFS /etc/exports file to a DB file, >> so support of that does not seem to be needed. >> >> I see this as useful for the ZFS share property case, >> so if that works correctly, I do not see the above as a concern. >> >> >> No, the ZFS share property stuff never generates the V4: line(s) so it’s not a problem for the /etc/zfs/exports.db case. >> >> And converting /etc/exports to /etc/exports.db is not really necessary from a performance point since I doubt it ever will be very long. >> However I bet some enthusiastic fellow is bound to try to do it sometime in the future just because it can be done :-) >> > Yep. Capturing this in a man page update when the time comes needs > to be done, I think? (That the V4: line doesn't work in the DB.) > >> >> >> Multiline options - well, the current ZFS code doesn’t support it either so no change from the current setup but it would be nice to have. >> Ie, support for things like: >> /export -sec=krb5 >> /export -sec=sys ro >> >> Yes. There is at least one PR that requests that the ZFS share property >> be enhanced to do this. Part of the reason for getting this patch in main >> is so that this can be pursued. >> >> Again, I only see this as a ZFS share property issue because I do not >> see any reason to convert /etc/exports flat files to db files? >> >> >> I agree that the need probably isn’t there. >> >> The current DB code will generate a syslog(LOG_ERR) warning if it detects anything not starting with / in the keys (and ignores it). >> >> Perhaps there should be a warning in the manual for mountd about not trying to convert /etc/exports into a DB (if it uses NFSv4 / the “V4:” line(s)). >> Or should we just special-case /etc/exports and forbid the check for /etc/exports.db? >> >> - Peter >> >> rick >> >> >> >> >> >> >> (I also agree that the USE_SHAREDB probably should be removed, I just have that here for now so that I can quickly disable the code) >> >> Regarding the patch to the zfs part - I’m not sure which way to go there - the current patch switches to always use the DB. But one could argue that the code could check for an existing /etc/zfs/exports.db and only use the DB-writing code if that already exists. That way it will support both the old way and the new way, but it requires an empty /etc/zfs/exports.db to be pre-created at initial boot time for it to start using it. > > That's up to the ZFS folk. Hopefully kevans@ can figure it out. > I was going to massage it a bit before passing it up for review; my preference (that I think will make it fairly easy to accept upstream) is that we simply prefer exports.db if it exists but otherwise don't change anything for the folks happy with their current setup -- at least for an interim period, at a minimum. Thanks, Kyle Evans