From owner-freebsd-fs@freebsd.org Sun Jul 21 17:07:20 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E8F03B85E8 for ; Sun, 21 Jul 2019 17:07:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id C1C4E87AC2 for ; Sun, 21 Jul 2019 17:07:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id C1373B85E7; Sun, 21 Jul 2019 17:07:20 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C0C0DB85E5 for ; Sun, 21 Jul 2019 17:07:20 +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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2D2387ABF for ; Sun, 21 Jul 2019 17:07:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7F868266BA for ; Sun, 21 Jul 2019 17:07:20 +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 x6LH7KTg098798 for ; Sun, 21 Jul 2019 17:07:20 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6LH7KOk098797 for fs@FreeBSD.org; Sun, 21 Jul 2019 17:07:20 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 237397] 'zfs mount -a' mounts filesystems in incorrect order Date: Sun, 21 Jul 2019 17:07:19 +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: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fullermd@over-yonder.net 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 MIME-Version: 1.0 X-Rspamd-Queue-Id: A2D2387ABF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 17:07:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237397 fullermd@over-yonder.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fullermd@over-yonder.net --- Comment #5 from fullermd@over-yonder.net --- See earlier ref'd bug 237517 now contains a fix from ZoL. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Jul 21 21:01:24 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2692FBE829 for ; Sun, 21 Jul 2019 21:01:24 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id E46916C593 for ; Sun, 21 Jul 2019 21:01:23 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id D3B03BE80E; Sun, 21 Jul 2019 21:01:22 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D29DFBE80D for ; Sun, 21 Jul 2019 21:01:22 +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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88CD56C56E for ; Sun, 21 Jul 2019 21:01:22 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 3BA4D15C1 for ; Sun, 21 Jul 2019 21:01:20 +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 x6LL1KGP053424 for ; Sun, 21 Jul 2019 21:01:20 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6LL1KFB053423 for fs@FreeBSD.org; Sun, 21 Jul 2019 21:01:20 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201907212101.x6LL1KFB053423@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, 21 Jul 2019 21:01:20 +0000 MIME-Version: 1.0 X-Rspamd-Queue-Id: E46916C593 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 21:01:24 -0000 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 ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f Open | 211491 | System hangs after "Uptime" on reboot with ZFS Open | 221909 | [ZFS] Add a sysctl to toggle send_corrupt_data Open | 235665 | panic: handle_written_inodeblock: live inodedep Open | 237067 | ZFS: Crash in vdev_dtl_reassess when using GELI w 6 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Sun Jul 21 23:52:04 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 93644A2C44 for ; Sun, 21 Jul 2019 23:52:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 2456870804 for ; Sun, 21 Jul 2019 23:52:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 234EBA2C43; Sun, 21 Jul 2019 23:52:04 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 22063A2C42 for ; Sun, 21 Jul 2019 23:52:04 +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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2D7970800 for ; Sun, 21 Jul 2019 23:52:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C9A9A36BE for ; Sun, 21 Jul 2019 23:52:03 +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 x6LNq3Jr070655 for ; Sun, 21 Jul 2019 23:52:03 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6LNq3pO070654 for fs@FreeBSD.org; Sun, 21 Jul 2019 23:52:03 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 237517] ZFS parallel mounting sometimes misses mounting intermediate filesystems Date: Sun, 21 Jul 2019 23:51:58 +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: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: junchoon@dec.sakura.ne.jp 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 MIME-Version: 1.0 X-Rspamd-Queue-Id: 2456870804 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 23:52:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237517 Tomoaki AOKI changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |junchoon@dec.sakura.ne.jp --- Comment #16 from Tomoaki AOKI --- (In reply to fullermd from comment #15) Thanks. This seem to fix my problem. My problem was that datasets manually imported (after boot) pools usually wasn't mounted properly. Not accessible until manual unmount / mount for it is done. Note that it rarely succeeded on import, so there should be some race. This is why I cannot clearly state FIXED. I would need several months to be sure, as I had 1 or 2 succeeds after init= ial commit of parallel-mounting was done. BTW, is this change possible to commit? I'm afraid there can be licensing problem (GPL pollution), as this doesn't seem to be in Illumos currently. If this change can be (dual) licensed with CDDL (or BSD), it would be OK. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Jul 22 15:49:02 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 170B6B473C for ; Mon, 22 Jul 2019 15:49:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id EB62674EC4 for ; Mon, 22 Jul 2019 15:49:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id E9344B473B; Mon, 22 Jul 2019 15:49:01 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E8F95B473A for ; Mon, 22 Jul 2019 15:49:01 +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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB2B774EC3 for ; Mon, 22 Jul 2019 15:49:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A55ECF733 for ; Mon, 22 Jul 2019 15:49:01 +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 x6MFn1B1014456 for ; Mon, 22 Jul 2019 15:49:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6MFn1mt014455 for fs@FreeBSD.org; Mon, 22 Jul 2019 15:49:01 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 237517] ZFS parallel mounting sometimes misses mounting intermediate filesystems Date: Mon, 22 Jul 2019 15:48:59 +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: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bsdpr@phoe.frmug.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 MIME-Version: 1.0 X-Rspamd-Queue-Id: EB62674EC4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.977,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:49:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237517 Bertrand Petit changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bsdpr@phoe.frmug.org --- Comment #17 from Bertrand Petit --- I confirm that attachment 205857 fixes the problem I reported separately at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239243 for 11.3-STABLE. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Jul 22 20:03:14 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C71D6BAA78 for ; Mon, 22 Jul 2019 20:03:14 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2948988A67 for ; Mon, 22 Jul 2019 20:03:13 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: by mail-vs1-xe2e.google.com with SMTP id a186so25552559vsd.7 for ; Mon, 22 Jul 2019 13:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RuLFhJ4HB9BYC4XWCeMABloAwTL0AnF1dHUV9l/oDd0=; b=Ew2nWKhbxcgXockNLWnTQPeqH/ZaMUrFPZsCDxdc0IC9ECBbfTtFUAQkjC4CRlfqCx nTVcIxJx+nLo++Ut7ZtlgOB+cneahrA0qndRww4WUb/HQxnqzPK0QDErmIk1NuLPlXVe as+boKu17eMJ1H/Q5hB/AnQy3SxRIbDLUrXS4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RuLFhJ4HB9BYC4XWCeMABloAwTL0AnF1dHUV9l/oDd0=; b=swlYJcU+h9p+Oq1wBCUID1XUvngvskMCWX/Z2C2fiuvw3IgvXaRJhR1idCNLC/IiHF 29y75aNrAOE/ihpEIy0m+t0eh+yYfb5nSMHOUwrpOYA/Ps0Q66yccUzoX9MHksFAK+WL HQ/A7LA81fHg1TUutokg8SmaUblh8spSXhi/n0yuFn3mcY+nN52D6nmBD+JFVB//um53 LRoIeJPdjjUJC25a2lV52F9XDw77eiWZghB7e0soA5GD6ScoVdyNTkLpJ0i5NtEtaVXp QNUippwr2+jdgigI2rnq4Ut8ur+5UZMo6W23Hy6VVoCmzZ37nLMdGpU74IrOuW1NA/wo 8CcA== X-Gm-Message-State: APjAAAVxdCQH7S9JQAHsUHc8MWANym3Ymc8pmE2wl+8xzyCCIlK8UOyz 0XjEwrmmqB5NW82ZMnbgMiSVDIGCrLUlTRD4ZJFCaQ== X-Google-Smtp-Source: APXvYqwZmbrxMGS9Jr/t0GfAQdMQsL5g5BWMnp/+mC7Ndb97EbzcmAUTnmUyjqgUtJdNuX7skaBSjde1LVZZuuMn3Vk= X-Received: by 2002:a67:e8c3:: with SMTP id y3mr43337208vsn.94.1563825792304; Mon, 22 Jul 2019 13:03:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Ahrens Date: Mon, 22 Jul 2019 13:03:01 -0700 Message-ID: Subject: July OpenZFS Leadership Meeting To: developer , illumos-zfs , zfs-devel@list.zfsonlinux.org, zfs-devel@freebsd.org, freebsd-fs , zfs-discuss X-Rspamd-Queue-Id: 2948988A67 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=delphix.com header.s=google header.b=Ew2nWKhb; dmarc=pass (policy=none) header.from=delphix.com; spf=pass (mx1.freebsd.org: domain of matthew.ahrens@delphix.com designates 2607:f8b0:4864:20::e2e as permitted sender) smtp.mailfrom=matthew.ahrens@delphix.com X-Spamd-Result: default: False [-6.59 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[delphix.com:s=google]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; RCPT_COUNT_FIVE(0.00)[6]; NEURAL_HAM_SHORT(-0.82)[-0.825,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[delphix.com:+]; DMARC_POLICY_ALLOW(-0.50)[delphix.com,none]; RCVD_IN_DNSWL_NONE(0.00)[e.2.e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,aspmx2.googlemail.com,alt2.aspmx.l.google.com,aspmx3.googlemail.com]; IP_SCORE(-3.06)[ip: (-9.70), ipnet: 2607:f8b0::/32(-3.11), asn: 15169(-2.43), country: US(-0.05)]; FORGED_SENDER(0.30)[mahrens@delphix.com,matthew.ahrens@delphix.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[mahrens@delphix.com,matthew.ahrens@delphix.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 20:03:14 -0000 The next OpenZFS Leadership meeting will be held tomorrow, July 23, 11am-noon Pacific time. Everyone is welcome to attend and participate, and we will try to keep the meeting on agenda and on time. The meetings will be held online via Zoom, and recorded and posted to the website and YouTube after the meeting. The agenda for the meeting will be a discussion of the projects listed in the agenda doc. For more information and details on how to attend, as well as notes and video from the previous meeting, please see the agenda document: https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit --matt From owner-freebsd-fs@freebsd.org Wed Jul 24 19:29:16 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 08CC7B6121 for ; Wed, 24 Jul 2019 19:29:16 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E27786F723 for ; Wed, 24 Jul 2019 19:29:14 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: by mail-vs1-xe30.google.com with SMTP id v6so32161248vsq.4 for ; Wed, 24 Jul 2019 12:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HQOhM3ZhO5C03Lzmk4gcwuPi6AhyzQACwz5PLc9zG9U=; b=XEyS3lk1XBgoVjwjWRGXADrHtv24YKl31jQtALlDdxxF+On92jvxutez8dexm6HZjJ Po0oq6zC1NDWm/n+HzInlRBZ/4nBoqIgJF29BJjNhxTNaMDkFQa+qXYYynwpuweG2ECk np5ZGKoRrH+nVlWU/RONxGtqj6eW6oIGI3PEM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HQOhM3ZhO5C03Lzmk4gcwuPi6AhyzQACwz5PLc9zG9U=; b=BHbC+RGSdEP1VW0yQlfLqEvMKiYVsL8hQtM2YH9KjUC6NyqLt2bUnqLYpzEI3pPr8O hyWvXlV02/tu7I1pbu9QRV+fRiN1u0FfwlHmwTOamhjfKzL8nO/fJJ1AwPk4wgTCH0Fo D4P65kSmH+Qc95NGlq468BcfYW6HsCb6p6mfIQ0RdkuluWuy+0y9ysdSyiVkPQQsPQ0K HFfZjdn1a/LKeoUFnOIp4QHsIgZ+FpvmsUf+zFUKIO3++VZmtEB0/O/Z6Qy+gQKmzBCd V22qI0WdU01hp+tSo1y/7JesQfdtes+8V+Mr5MkGWuJL4RCqHJvdb2gLOaoNLR2VsMc4 o1Xw== X-Gm-Message-State: APjAAAXY9kmf615pDe2IhxBL1LaJxYxUEE64jwlevdmvbAnGortlVpr3 FPYTtXS2NQQG03kjV2clCSZQUGiGDevKp5LW3A2jTCPqYos= X-Google-Smtp-Source: APXvYqwuR4OU/Ffh/C3QhlQlOQgWHDWvj2aQFi1YKmMLheirreOwSrkC+QE19/io/6tibGmWpnDc+iZi0Bnla24vEIQ= X-Received: by 2002:a05:6102:3c5:: with SMTP id n5mr14383131vsq.56.1563996553997; Wed, 24 Jul 2019 12:29:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Ahrens Date: Wed, 24 Jul 2019 12:29:02 -0700 Message-ID: Subject: Re: July OpenZFS Leadership Meeting To: developer , illumos-zfs , zfs-devel@list.zfsonlinux.org, zfs-devel@freebsd.org, freebsd-fs , zfs-discuss X-Rspamd-Queue-Id: E27786F723 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=delphix.com header.s=google header.b=XEyS3lk1; dmarc=pass (policy=none) header.from=delphix.com; spf=pass (mx1.freebsd.org: domain of matthew.ahrens@delphix.com designates 2607:f8b0:4864:20::e30 as permitted sender) smtp.mailfrom=matthew.ahrens@delphix.com X-Spamd-Result: default: False [-6.71 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[delphix.com:s=google]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; RCPT_COUNT_FIVE(0.00)[6]; NEURAL_HAM_SHORT(-0.94)[-0.941,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[delphix.com:+]; DMARC_POLICY_ALLOW(-0.50)[delphix.com,none]; RCVD_IN_DNSWL_NONE(0.00)[0.3.e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,aspmx2.googlemail.com,alt2.aspmx.l.google.com,aspmx3.googlemail.com]; IP_SCORE(-3.06)[ip: (-9.71), ipnet: 2607:f8b0::/32(-3.09), asn: 15169(-2.43), country: US(-0.05)]; FORGED_SENDER(0.30)[mahrens@delphix.com,matthew.ahrens@delphix.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[mahrens@delphix.com,matthew.ahrens@delphix.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 19:29:16 -0000 The video and meeting notes are now available: https://www.youtube.com/watch?v=3DltIIDDq9qag&feature=3Dyoutu.be - ZoL + SIMD + Linux 5.0 (Matt) - Brian integrated some support for this already but he is currently on vacation - 5.0+ made some changes to the floating point registers that were used by ZoL for SIMD instructions - Brian reimplemented some of those in ZoL and now these instructions work again and will be backported in 0.8 - Needed for performant RAIDZ, Encryption, and some compression algorithms - Used only if the underlying CPU architecture actually supported (checked during runtime) - OpenZFS Developer Summit (Matt) - Announced: Nov 4-5. Same locations as last year in SF. - Registration and call for papers is open. Please submit a talk and tell us about the cool stuff you=E2=80=99re doing with ZFS - We appreciate people volunteering to help out with things for the conference. - Karyn will reach out to Rainbow about help with AV. - Ticket prices went up to $100. There are some discount tickets available, and let us know if the pricing is a hardship and we can tr= y to figure something out. - FreeBSD Foundation may have travel grants available if want to apply - Get all the details (including a link to the registration site) on the OpenZFS wiki page - Property to track amount of queued TRIM/UNMAP (like =E2=80=9Cfreeing=E2= =80=9D for async destroy) (Allan) - Allan Jude: users may want to know how many trim/unmapped is left or in-progress before performing other actions instead of performing the= pool - Matt: Maybe a flag to zpool sync =E2=80=94trim that could wait for al= l trim activity to be done. Probably better than the existing proposal where= we have a property like freeing for it, which would jump up and down - `zpool wait` that is about to be upstreamed from Delphix and should be a good candidate to add this functionality. You can look at the Delphix repo if you want to see it before the PR. - RAIDZ removal issue with design ideas (Igor) - RAIDZ expansion progress (Matt) - No progress to report since preview posted - The hope is to have takers to test it out - The functionality is there, there are on-disk format changes (so don't use it in production), a few race conditions being fixed and so= me more error handling for device failures. - Important to note that even though we can expand the RAIDZ we still can't remove devices (e.g. zpool remove) - ZoL PR exists with design considerations for the feature - OpenZFS feature matrix (everyone) - FreeBSD is hoping to catch up with ZoL through the ZoF work - NFSv4 ACL PR waiting for code review - should we consider tracking this in the feature Matrix? - Update: Added - Note: already on illumos On Mon, Jul 22, 2019 at 1:03 PM Matthew Ahrens wrote: > The next OpenZFS Leadership meeting will be held tomorrow, July 23, > 11am-noon Pacific time. > > Everyone is welcome to attend and participate, and we will try to keep th= e > meeting on agenda and on time. The meetings will be held online via Zoom= , > and recorded and posted to the website and YouTube after the meeting. > > The agenda for the meeting will be a discussion of the projects listed in > the agenda doc. > > For more information and details on how to attend, as well as notes and > video from the previous meeting, please see the agenda document: > > > https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnW= HhV-BM/edit > > --matt > From owner-freebsd-fs@freebsd.org Fri Jul 26 03:05:47 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 93FDFB47F5 for ; Fri, 26 Jul 2019 03:05:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7686172C22 for ; Fri, 26 Jul 2019 03:05:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 75F8AB47F4; Fri, 26 Jul 2019 03:05:47 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 75B13B47F3 for ; Fri, 26 Jul 2019 03:05:47 +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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58B6C72C21 for ; Fri, 26 Jul 2019 03:05:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 353BE8B70 for ; Fri, 26 Jul 2019 03:05:47 +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 x6Q35lem025739 for ; Fri, 26 Jul 2019 03:05:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6Q35lNF025733 for fs@FreeBSD.org; Fri, 26 Jul 2019 03:05:47 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 239243] [zfs] regression: "zfs mount -a" mount order is incorrect became incorrect Date: Fri, 26 Jul 2019 03:05:47 +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: 11.3-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@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: assigned_to 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 MIME-Version: 1.0 X-Rspamd-Queue-Id: 58B6C72C21 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 03:05:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239243 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Jul 26 13:12:51 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 81EE7BFEE3 for ; Fri, 26 Jul 2019 13:12:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 54B7F680CA for ; Fri, 26 Jul 2019 13:12:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 0B733BFEDF; Fri, 26 Jul 2019 13:12:51 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0B390BFEDE for ; Fri, 26 Jul 2019 13:12: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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCDC6680C0 for ; Fri, 26 Jul 2019 13:12:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 178D3FAAF for ; Fri, 26 Jul 2019 13:12:45 +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 x6QDCi9Y028334 for ; Fri, 26 Jul 2019 13:12:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6QDCiVZ028333 for fs@FreeBSD.org; Fri, 26 Jul 2019 13:12:44 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 239243] [zfs] regression: "zfs mount -a" mount order is incorrect became incorrect Date: Fri, 26 Jul 2019 13:12:44 +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: 11.3-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@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: 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 MIME-Version: 1.0 X-Rspamd-Queue-Id: 54B7F680CA X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.962,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 13:12:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239243 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: bapt Date: Fri Jul 26 13:12:33 UTC 2019 New revision: 350358 URL: https://svnweb.freebsd.org/changeset/base/350358 Log: Fix a bug introduced with parallel mounting of zfs Incorporate a fix from zol: =20 https://github.com/zfsonlinux/zfs/commit/ab5036df1ccbe1b18c1ce6160b5829e803= 9d94ce commit log from upstream: Fix race in parallel mount's thread dispatching algorithm Strategy of parallel mount is as follows. 1) Initial thread dispatching is to select sets of mount points that don't have dependencies on other sets, hence threads can/should run lock-less and shouldn't race with other threads for other sets. Each thread dispatched corresponds to top level directory which may or may not have datasets to be mounted on sub directories. 2) Subsequent recursive thread dispatching for each thread from 1) is to mount datasets for each set of mount points. The mount points within each set have dependencies (i.e. child directories), so child directories are processed only after parent directory completes. The problem is that the initial thread dispatching in zfs_foreach_mountpoint() can be multi-threaded when it needs to be single-threaded, and this puts threads under race condition. This race appeared as mount/unmount issues on ZoL for ZoL having different timing regarding mount(2) execution due to fork(2)/exec(2) of mount(8). `zfs unmount -a` which expects proper mount order can't unmount if the mounts were reordered by the race condition. There are currently two known patterns of input list `handles` in `zfs_foreach_mountpoint(..,handles,..)` which cause the race condition. 1) #8833 case where input is `/a /a /a/b` after sorting. The problem is that libzfs_path_contains() can't correctly handle an input list with two same top level directories. There is a race between two POSIX threads A and B, * ThreadA for "/a" for test1 and "/a/b" * ThreadB for "/a" for test0/a and in case of #8833, ThreadA won the race. Two threads were created because "/a" wasn't considered as `"/a" contains "/a"`. 2) #8450 case where input is `/ /var/data /var/data/test` after sorting. The problem is that libzfs_path_contains() can't correctly handle an input list containing "/". There is a race between two POSIX threads A and B, * ThreadA for "/" and "/var/data/test" * ThreadB for "/var/data" and in case of #8450, ThreadA won the race. Two threads were created because "/var/data" wasn't considered as `"/" contains "/var/data"`. In other words, if there is (at least one) "/" in the input list, the initial thread dispatching must be single-threaded since every directory is a child of "/", meaning they all directly or indirectly depend on "/". In both cases, the first non_descendant_idx() call fails to correctly determine "path1-contains-path2", and as a result the initial thread dispatching creates another thread when it needs to be single-threaded. Fix a conditional in libzfs_path_contains() to consider above two. Reviewed-by: Brian Behlendorf Reviewed by: Sebastien Roy Signed-off-by: Tomohiro Kusumi PR: 237517, 237397, 239243 Submitted by: Matthew D. Fuller (by email) MFC after: 3 days Changes: head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_mount.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Jul 26 13:12:52 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 308B3BFEF6 for ; Fri, 26 Jul 2019 13:12:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id BAFC3680D1 for ; Fri, 26 Jul 2019 13:12:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id BA78CBFEEB; Fri, 26 Jul 2019 13:12:51 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BA2CFBFEEA for ; Fri, 26 Jul 2019 13:12: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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94BE0680CD for ; Fri, 26 Jul 2019 13:12:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 87317FAB5 for ; Fri, 26 Jul 2019 13:12:46 +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 x6QDCk2W028416 for ; Fri, 26 Jul 2019 13:12:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6QDCk7o028415 for fs@FreeBSD.org; Fri, 26 Jul 2019 13:12:46 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 237397] 'zfs mount -a' mounts filesystems in incorrect order Date: Fri, 26 Jul 2019 13:12:46 +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: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@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: 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 MIME-Version: 1.0 X-Rspamd-Queue-Id: BAFC3680D1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.962,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 13:12:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237397 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: bapt Date: Fri Jul 26 13:12:33 UTC 2019 New revision: 350358 URL: https://svnweb.freebsd.org/changeset/base/350358 Log: Fix a bug introduced with parallel mounting of zfs Incorporate a fix from zol: =20 https://github.com/zfsonlinux/zfs/commit/ab5036df1ccbe1b18c1ce6160b5829e803= 9d94ce commit log from upstream: Fix race in parallel mount's thread dispatching algorithm Strategy of parallel mount is as follows. 1) Initial thread dispatching is to select sets of mount points that don't have dependencies on other sets, hence threads can/should run lock-less and shouldn't race with other threads for other sets. Each thread dispatched corresponds to top level directory which may or may not have datasets to be mounted on sub directories. 2) Subsequent recursive thread dispatching for each thread from 1) is to mount datasets for each set of mount points. The mount points within each set have dependencies (i.e. child directories), so child directories are processed only after parent directory completes. The problem is that the initial thread dispatching in zfs_foreach_mountpoint() can be multi-threaded when it needs to be single-threaded, and this puts threads under race condition. This race appeared as mount/unmount issues on ZoL for ZoL having different timing regarding mount(2) execution due to fork(2)/exec(2) of mount(8). `zfs unmount -a` which expects proper mount order can't unmount if the mounts were reordered by the race condition. There are currently two known patterns of input list `handles` in `zfs_foreach_mountpoint(..,handles,..)` which cause the race condition. 1) #8833 case where input is `/a /a /a/b` after sorting. The problem is that libzfs_path_contains() can't correctly handle an input list with two same top level directories. There is a race between two POSIX threads A and B, * ThreadA for "/a" for test1 and "/a/b" * ThreadB for "/a" for test0/a and in case of #8833, ThreadA won the race. Two threads were created because "/a" wasn't considered as `"/a" contains "/a"`. 2) #8450 case where input is `/ /var/data /var/data/test` after sorting. The problem is that libzfs_path_contains() can't correctly handle an input list containing "/". There is a race between two POSIX threads A and B, * ThreadA for "/" and "/var/data/test" * ThreadB for "/var/data" and in case of #8450, ThreadA won the race. Two threads were created because "/var/data" wasn't considered as `"/" contains "/var/data"`. In other words, if there is (at least one) "/" in the input list, the initial thread dispatching must be single-threaded since every directory is a child of "/", meaning they all directly or indirectly depend on "/". In both cases, the first non_descendant_idx() call fails to correctly determine "path1-contains-path2", and as a result the initial thread dispatching creates another thread when it needs to be single-threaded. Fix a conditional in libzfs_path_contains() to consider above two. Reviewed-by: Brian Behlendorf Reviewed by: Sebastien Roy Signed-off-by: Tomohiro Kusumi PR: 237517, 237397, 239243 Submitted by: Matthew D. Fuller (by email) MFC after: 3 days Changes: head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_mount.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Jul 26 13:12:51 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 68921BFEE0 for ; Fri, 26 Jul 2019 13:12:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE22680C5 for ; Fri, 26 Jul 2019 13:12:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 2EDA0BFED2; Fri, 26 Jul 2019 13:12:50 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2E84FBFED1 for ; Fri, 26 Jul 2019 13:12:50 +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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B321680B1 for ; Fri, 26 Jul 2019 13:12:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 91362FAAC for ; Fri, 26 Jul 2019 13:12:43 +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 x6QDChHN028318 for ; Fri, 26 Jul 2019 13:12:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6QDCh4h028317 for fs@FreeBSD.org; Fri, 26 Jul 2019 13:12:43 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 237517] ZFS parallel mounting sometimes misses mounting intermediate filesystems Date: Fri, 26 Jul 2019 13:12:40 +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: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@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: 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 MIME-Version: 1.0 X-Rspamd-Queue-Id: 2DE22680C5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.962,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 13:12:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237517 --- Comment #18 from commit-hook@freebsd.org --- A commit references this bug: Author: bapt Date: Fri Jul 26 13:12:33 UTC 2019 New revision: 350358 URL: https://svnweb.freebsd.org/changeset/base/350358 Log: Fix a bug introduced with parallel mounting of zfs Incorporate a fix from zol: =20 https://github.com/zfsonlinux/zfs/commit/ab5036df1ccbe1b18c1ce6160b5829e803= 9d94ce commit log from upstream: Fix race in parallel mount's thread dispatching algorithm Strategy of parallel mount is as follows. 1) Initial thread dispatching is to select sets of mount points that don't have dependencies on other sets, hence threads can/should run lock-less and shouldn't race with other threads for other sets. Each thread dispatched corresponds to top level directory which may or may not have datasets to be mounted on sub directories. 2) Subsequent recursive thread dispatching for each thread from 1) is to mount datasets for each set of mount points. The mount points within each set have dependencies (i.e. child directories), so child directories are processed only after parent directory completes. The problem is that the initial thread dispatching in zfs_foreach_mountpoint() can be multi-threaded when it needs to be single-threaded, and this puts threads under race condition. This race appeared as mount/unmount issues on ZoL for ZoL having different timing regarding mount(2) execution due to fork(2)/exec(2) of mount(8). `zfs unmount -a` which expects proper mount order can't unmount if the mounts were reordered by the race condition. There are currently two known patterns of input list `handles` in `zfs_foreach_mountpoint(..,handles,..)` which cause the race condition. 1) #8833 case where input is `/a /a /a/b` after sorting. The problem is that libzfs_path_contains() can't correctly handle an input list with two same top level directories. There is a race between two POSIX threads A and B, * ThreadA for "/a" for test1 and "/a/b" * ThreadB for "/a" for test0/a and in case of #8833, ThreadA won the race. Two threads were created because "/a" wasn't considered as `"/a" contains "/a"`. 2) #8450 case where input is `/ /var/data /var/data/test` after sorting. The problem is that libzfs_path_contains() can't correctly handle an input list containing "/". There is a race between two POSIX threads A and B, * ThreadA for "/" and "/var/data/test" * ThreadB for "/var/data" and in case of #8450, ThreadA won the race. Two threads were created because "/var/data" wasn't considered as `"/" contains "/var/data"`. In other words, if there is (at least one) "/" in the input list, the initial thread dispatching must be single-threaded since every directory is a child of "/", meaning they all directly or indirectly depend on "/". In both cases, the first non_descendant_idx() call fails to correctly determine "path1-contains-path2", and as a result the initial thread dispatching creates another thread when it needs to be single-threaded. Fix a conditional in libzfs_path_contains() to consider above two. Reviewed-by: Brian Behlendorf Reviewed by: Sebastien Roy Signed-off-by: Tomohiro Kusumi PR: 237517, 237397, 239243 Submitted by: Matthew D. Fuller (by email) MFC after: 3 days Changes: head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_mount.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Jul 27 16:39:57 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 76029BD5A9 for ; Sat, 27 Jul 2019 16:39:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670057.outbound.protection.outlook.com [40.107.67.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D950E8C6C1; Sat, 27 Jul 2019 16:39:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FDxHTOLYHVl2dNVX8UTkHmoQ0xis7D1zIOHxRPBZcnEmYGTrIDeZbGRSt8nyBk9vlaWoEiPj8/JVT1Vv3l8WZpu4BxcAEVA/aYkoCkkjaHo8TyhavrP2icnwqW+QBH1hDNwcfCQPDQ+F3J7MPFHiJqOqjyKUvre8lrZ9mGCOGrwFxg+U5AG8VPCHXxwOE/KVxt61yE7NtcvXAmG/iq8UuHe2CtYEDA+tkYGQTvIuFhiQ+DHvM/IRK8QgmfsAFdcggj1BIy2bF2RXgB3hwIw3YaJxKfhn8zkt+OGtNvsxJBreVXFUU8Q9Ol4498deX5/3Ag3xQ9pAG45A+Q/zl9i79g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m12aO7gGeSktlCKh/L2aStY+Sl80CP86EOzjhztpDhc=; b=mzJSDlql1Ub5nyRiO+u/PuTKHgN3EnZEGFbKCHsnjtOHqKFCxueQ8f3jHAJYkOtLxIiu5N2MI9JOLh4hRbzwZGVnVWJtSCnnkE6vHTzufAr6qtMt9v9ZzKqzs+v+arMpO26vnWBVGKw5Tn8BH316MkUe1gbfG9cie89XM+LC8X3set7wwMBDPWKXV8ahM+UNNvDndDnoFNdNLG0uhYimGMcGhqnR6D18WvUaVEB0PpGg644Octl8JD75d0OfB+J09I5kL1UoDuQ+br6E2BktVnPtRewvFzw9YkVRKB7FtY8GjvCWKys/XBL+fInlnNifjd+LBtOBsXxz9zOb3TEe7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=uoguelph.ca;dmarc=pass action=none header.from=uoguelph.ca;dkim=pass header.d=uoguelph.ca;arc=none Received: from YTBPR01MB3312.CANPRD01.PROD.OUTLOOK.COM (10.255.13.158) by YTBPR01MB3646.CANPRD01.PROD.OUTLOOK.COM (10.255.12.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.14; Sat, 27 Jul 2019 16:39:54 +0000 Received: from YTBPR01MB3312.CANPRD01.PROD.OUTLOOK.COM ([fe80::70d6:627b:b391:3977]) by YTBPR01MB3312.CANPRD01.PROD.OUTLOOK.COM ([fe80::70d6:627b:b391:3977%7]) with mapi id 15.20.2115.005; Sat, 27 Jul 2019 16:39:53 +0000 From: Rick Macklem To: "freebsd-fs@freebsd.org" CC: "kib@freebsd.org" Subject: RFC: should copy_file_range(2) use size_t or off_t for length argument Thread-Topic: RFC: should copy_file_range(2) use size_t or off_t for length argument Thread-Index: AQHVRJjy4L2Al+2Bt0mzzLUcIw9tbQ== Date: Sat, 27 Jul 2019 16:39:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2648cc19-ee4a-48a2-b6a7-08d712b10d65 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YTBPR01MB3646; x-ms-traffictypediagnostic: YTBPR01MB3646: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01110342A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(376002)(346002)(136003)(78114003)(199004)(189003)(6436002)(74316002)(305945005)(4326008)(2906002)(316002)(786003)(450100002)(6916009)(478600001)(6506007)(71190400001)(71200400001)(7696005)(33656002)(256004)(14454004)(102836004)(186003)(25786009)(53936002)(9686003)(46003)(55016002)(66556008)(64756008)(66446008)(81166006)(81156014)(8936002)(8676002)(66946007)(476003)(486006)(2501003)(2351001)(99286004)(52536014)(86362001)(68736007)(76116006)(66476007)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTBPR01MB3646; H:YTBPR01MB3312.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 60h+oKAd+pV3Pd18G9Gog7/LNgsSdfJz4Sj4Om25zxAFH0HaekxwUviywH5o88lJE5ZEacMgXTwn/LN9WwUOZzR4SaZYWG6t75BHSIae3JoVQUAfzLQGIlpL/Ono1xU2zi5Am5irpqht+u6gTpNHCkFThYproyNPC+EJ4wNE9futaSkuQAVz4WlsR+2QcJ7ECDMDRCHknQcw5hB4fbsn3Ec57dY9gX1HoOkk6vUXY/JS7ic6yVf4rY9UtWYpWLBMIEVAF8CqoeBZl5xne8pgSNRcnDdgLd8dPkRktqDPUKHPygOW69/JnnI2dbZhQRKUqf4Nj+lB3citReEDC6QmW/9UMLe43zpHYwwny5UCFuN48yNB2MV9NX55lYkJybPq5QYKdEQuBrOjyx0BCZU6itNKbMooGxKcipnEDuIpnaM= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 2648cc19-ee4a-48a2-b6a7-08d712b10d65 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2019 16:39:53.7726 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3646 X-Rspamd-Queue-Id: D950E8C6C1 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.57 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.22 / 15.00]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.09)[ipnet: 40.64.0.0/10(-3.06), asn: 8075(-2.33), country: US(-0.05)]; MX_GOOD(-0.01)[mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[57.67.107.40.list.dnswl.org : 127.0.3.0]; NEURAL_HAM_SHORT(-0.82)[-0.824,0]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 16:39:57 -0000 Hi, r350315 implemented a Linux compatible copy_file_range(2) syscall. Since Linux used a length argument of size_t and a return argument type of ssize_t, I did the same. Kostik has suggested that making these off_t would allow a full 64bit copy be done on 32bit arches. Here is the snippet of discussion we have had: Kostik Belousov wrote: > >Kostik Belousov wrote: >> >I sat to write the compat32 shims, and only then noted that len has siz= e_t >> >type. Why is it size_t and not off_t ? > I wrote: >> Well, that's what Linux did. >>=20 >> Also, since it returns ssize_t, it can't do more than SSIZE_MAX >> (generally 1/2 of SIZE_T_MAX). Returning ssize_t is also what Linux >> does and is consistent with read(2)/write(2). > >If changing the length argument type to off_t, it is reasonable to change >the return type to off_t as well. We already have the lseek(2) syscall th= at >requires two return registers on 32bit. > >Note that it is reasonable for read(2) to take length as size_t-typed >parameter, because size_t is the type for object sizes. There is no >object in user address space for copy_file_range(2) API, so potentially >wider off_t is acceptable and is in fact useful there. It is useful on >32bit machines where FreeBSD size_t is 32bit, while off_t is 64bit. So, what do others think? (My only concern w.r.t. changing the arguments to off_t is Linux compatibil= ity.) rick From owner-freebsd-fs@freebsd.org Sat Jul 27 17:17:25 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 06D8CBE243 for ; Sat, 27 Jul 2019 17:17:25 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 561F98DA09 for ; Sat, 27 Jul 2019 17:17:24 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io1-f66.google.com with SMTP id s7so111190876iob.11 for ; Sat, 27 Jul 2019 10:17:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=Gf+p+PP7x7Pp5W9KMWFwjCYzSMvDB+bq/OEo4BM9ZP4=; b=X8bCCpcj1QiqVUi/v5JUl6107AdIANZPFyHaVQp7TvxjTCspjU9mlhXJYS+3XA64wl LTPKpYB961bj9hloeEDlyYfRlfpCZUTHfOCVaZGmqob2A3NnGQEmOmET+jmvvuqezwlb 3rv3stZ2A5Wn0ai5+O1OxN0I/NxzjyHyFrk++dRwo0gVWqbOMsb1QgevRYamK9GQIQZa nuRr78gTCrxezFp6xYrS0nmxQSqc7Ud9x8tSQQhQh9/KE1FIhbKIdA3yWkEiWtCwrfCf IUXACRKWiKMGx0rkEwsfYZiQWgLHucTuNIcvq6QWa766MskAh/lXA8+dMWzPG6W118oq ZYPA== X-Gm-Message-State: APjAAAUW+1rk9OnIEnxqal4zx/5IipD/8zCoPTOB5QG7V7F9KTJr5KJf IxUs+svsed7NmAJScERhmWOp1Fhq X-Google-Smtp-Source: APXvYqyfBx8gD1Gm/uh+hD/d3H3o/gv7UjdeVWgzASTpOdGjknldy0psPYUbdFX2stc9SMb1r7FwrA== X-Received: by 2002:a5d:8416:: with SMTP id i22mr68120240ion.248.1564247842072; Sat, 27 Jul 2019 10:17:22 -0700 (PDT) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com. [209.85.166.43]) by smtp.gmail.com with ESMTPSA id z19sm66373818ioh.12.2019.07.27.10.17.21 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jul 2019 10:17:21 -0700 (PDT) Received: by mail-io1-f43.google.com with SMTP id z3so1630882iog.0 for ; Sat, 27 Jul 2019 10:17:21 -0700 (PDT) X-Received: by 2002:a5d:88c6:: with SMTP id i6mr71991428iol.107.1564247840934; Sat, 27 Jul 2019 10:17:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Sat, 27 Jul 2019 10:17:10 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: should copy_file_range(2) use size_t or off_t for length argument To: Rick Macklem Cc: "freebsd-fs@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 561F98DA09 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.66 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-4.21 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.91)[-0.908,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; IP_SCORE(-1.29)[ip: (-0.55), ipnet: 209.85.128.0/17(-3.42), asn: 15169(-2.44), country: US(-0.05)]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.166.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 17:17:25 -0000 Just my 2=C2=A2: keep the 1:1 Linux compatible interface. Requiring programs to loop over N x 2^31 copies of larger files on 32-bit platforms does not impose significant extra syscall burden on copy programs over the wider off_t, and it fits the pattern of many existing synchronous IO APIs (size_t lengths). I think there is some benefit to matching other OS's non-POSIX function APIs exactly when we choose to use those same names and concepts =E2=80=94 ifdef soup is painful. And developers target Linux firs= t. Cheers, Conrad On Sat, Jul 27, 2019 at 9:40 AM Rick Macklem wrote: > > Hi, > > r350315 implemented a Linux compatible copy_file_range(2) syscall. > Since Linux used a length argument of size_t and a return argument > type of ssize_t, I did the same. > > Kostik has suggested that making these off_t would allow a full 64bit > copy be done on 32bit arches. > Here is the snippet of discussion we have had: > Kostik Belousov wrote: > > >Kostik Belousov wrote: > >> >I sat to write the compat32 shims, and only then noted that len has s= ize_t > >> >type. Why is it size_t and not off_t ? > > I wrote: > >> Well, that's what Linux did. > >> > >> Also, since it returns ssize_t, it can't do more than SSIZE_MAX > >> (generally 1/2 of SIZE_T_MAX). Returning ssize_t is also what Linux > >> does and is consistent with read(2)/write(2). > > > >If changing the length argument type to off_t, it is reasonable to chang= e > >the return type to off_t as well. We already have the lseek(2) syscall = that > >requires two return registers on 32bit. > > > >Note that it is reasonable for read(2) to take length as size_t-typed > >parameter, because size_t is the type for object sizes. There is no > >object in user address space for copy_file_range(2) API, so potentially > >wider off_t is acceptable and is in fact useful there. It is useful on > >32bit machines where FreeBSD size_t is 32bit, while off_t is 64bit. > > So, what do others think? > (My only concern w.r.t. changing the arguments to off_t is Linux compatib= ility.) > > rick > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Sat Jul 27 23:34:52 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9A18BC418C for ; Sat, 27 Jul 2019 23:34:52 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B77FC72C66; Sat, 27 Jul 2019 23:34:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f193.google.com with SMTP id v24so55055867ljg.13; Sat, 27 Jul 2019 16:34:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/AkSf8N9ltyZq4q4/w9U/FysaJENbLun9N+xMuTrzp4=; b=rGyEauI/deO5+fLFqkcEFBdWIFKWK66ZkMmU/7P5LdGqWUChptBlQkHlxXz7iyyq8d YW8pP10w3gaGT7dte1M/dJT0bZrLInFr2d7IIUvgX9t2aslAbgvwfpVquVUf1MX5BkmW bZb+fqnvnvKlbG9OZBE7sKu9s02N4OSaV0hpJgTww7m88FmfIWm6RwB8xAbO81TILHK2 pXSAlM7L8xNKyiMlQT4aC89Ivy189KhLZhDQry0dSJcYCsxkSOg20Ik4kYlalt1RnWSR roGQ9TYo19Y96uAPomweBN9AVgFs1VtwBj7Zdlyft/GmLyIYNLZs7rfHRmRR1hFptEZP 9iTg== X-Gm-Message-State: APjAAAU008Jy1NevPCege8KBFIUeplQl8I9Y5BeD31oAj0bowaYlONMR EGBKGdftCGtZVWAwEPdDQ/bldgKbgilMazVVxUuhXQ== X-Google-Smtp-Source: APXvYqzRDqe4arcKlB6i3faYrf1kAAFzbHJ0WLVqJnrD3T5V7ebSNvSs4WB0x6OfKYKjGeA2e4RbcyA8DbKBhsKmvaw= X-Received: by 2002:a2e:9dc1:: with SMTP id x1mr53868142ljj.0.1564270044321; Sat, 27 Jul 2019 16:27:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 27 Jul 2019 17:27:12 -0600 Message-ID: Subject: Re: RFC: should copy_file_range(2) use size_t or off_t for length argument To: "Conrad E. Meyer" Cc: Rick Macklem , "freebsd-fs@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B77FC72C66 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.193 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.97 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.70)[-0.699,0]; RCVD_IN_DNSWL_NONE(0.00)[193.208.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.27)[ip: (-0.44), ipnet: 209.85.128.0/17(-3.42), asn: 15169(-2.44), country: US(-0.05)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[193.208.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 23:34:52 -0000 I agree. Full compatibility is more important than a slight boost to efficiency. -Alan On Sat, Jul 27, 2019 at 11:17 AM Conrad Meyer wrote: > > Just my 2=C2=A2: keep the 1:1 Linux compatible interface. Requiring > programs to loop over N x 2^31 copies of larger files on 32-bit > platforms does not impose significant extra syscall burden on copy > programs over the wider off_t, and it fits the pattern of many > existing synchronous IO APIs (size_t lengths). > > I think there is some benefit to matching other OS's non-POSIX > function APIs exactly when we choose to use those same names and > concepts =E2=80=94 ifdef soup is painful. And developers target Linux fi= rst. > > Cheers, > Conrad > > On Sat, Jul 27, 2019 at 9:40 AM Rick Macklem wrote= : > > > > Hi, > > > > r350315 implemented a Linux compatible copy_file_range(2) syscall. > > Since Linux used a length argument of size_t and a return argument > > type of ssize_t, I did the same. > > > > Kostik has suggested that making these off_t would allow a full 64bit > > copy be done on 32bit arches. > > Here is the snippet of discussion we have had: > > Kostik Belousov wrote: > > > >Kostik Belousov wrote: > > >> >I sat to write the compat32 shims, and only then noted that len has= size_t > > >> >type. Why is it size_t and not off_t ? > > > I wrote: > > >> Well, that's what Linux did. > > >> > > >> Also, since it returns ssize_t, it can't do more than SSIZE_MAX > > >> (generally 1/2 of SIZE_T_MAX). Returning ssize_t is also what Linux > > >> does and is consistent with read(2)/write(2). > > > > > >If changing the length argument type to off_t, it is reasonable to cha= nge > > >the return type to off_t as well. We already have the lseek(2) syscal= l that > > >requires two return registers on 32bit. > > > > > >Note that it is reasonable for read(2) to take length as size_t-typed > > >parameter, because size_t is the type for object sizes. There is no > > >object in user address space for copy_file_range(2) API, so potentiall= y > > >wider off_t is acceptable and is in fact useful there. It is useful on > > >32bit machines where FreeBSD size_t is 32bit, while off_t is 64bit. > > > > So, what do others think? > > (My only concern w.r.t. changing the arguments to off_t is Linux compat= ibility.) > > > > rick > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"