From owner-freebsd-hackers@freebsd.org Sun Sep 20 00:10:01 2020 Return-Path: Delivered-To: freebsd-hackers@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 4ADC93F39BA; Sun, 20 Sep 2020 00:10:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv7HX4ZHZz3SWc; Sun, 20 Sep 2020 00:10:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 08K09wYb047845 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 19 Sep 2020 17:09:58 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 08K09wC9047844; Sat, 19 Sep 2020 17:09:58 -0700 (PDT) (envelope-from sgk) Date: Sat, 19 Sep 2020 17:09:58 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH] libm -- fix expl kernels Message-ID: <20200920000958.GA47838@troutmask.apl.washington.edu> References: <20200919235849.GA47701@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200919235849.GA47701@troutmask.apl.washington.edu> X-Rspamd-Queue-Id: 4Bv7HX4ZHZz3SWc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.45 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.55)[-0.552]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.35)[-0.350]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-0.55)[-0.549]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 00:10:01 -0000 On Sat, Sep 19, 2020 at 04:58:49PM -0700, Steve Kargl wrote: > The following patch fixes the ld80 and ld128 kernels for expl(x). Subj: is slightly wrong. This fixes the cexpl(z) kernels. > I can't test ld128, so that patch is untested. > > . Micro-optimization: use sincosl(x) instead of a call to cosl(x) and > a call to sinl(x). Argument reduction is done once not twice. This part also fixes a cos(x) that should be cosl(x). > . Use a long double constant instead of an invalid double constant. > . Spell scale2 correctly -- Steve From owner-freebsd-hackers@freebsd.org Sun Sep 20 00:25:09 2020 Return-Path: Delivered-To: freebsd-hackers@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 19C6B3F446C; Sun, 20 Sep 2020 00:25:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv7d014F3z3TQ7; Sun, 20 Sep 2020 00:25:07 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 08K0P6sW047957 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 19 Sep 2020 17:25:06 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 08K0P68C047956; Sat, 19 Sep 2020 17:25:06 -0700 (PDT) (envelope-from sgk) Date: Sat, 19 Sep 2020 17:25:06 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: [PATCH] libm -- optimize __ldexp_cexp[f] Message-ID: <20200920002506.GA47948@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4Bv7d014F3z3TQ7 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.48 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.37)[-0.371]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_MEDIUM(-0.56)[-0.561]; NEURAL_HAM_SHORT(-0.55)[-0.552]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM, none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 00:25:09 -0000 The following patch is an opimization for he kernels used by cexp(x) and cexpf(x). . Use sincos[f] instead of a call to cos[f] and a call to sin[f]. . While here, alphabetize declaration. --- /usr/src/lib/msun/src/k_exp.c 2019-02-23 07:45:03.879997000 -0800 +++ src/k_exp.c 2019-12-26 08:15:30.109189000 -0800 @@ -88,7 +88,7 @@ double complex __ldexp_cexp(double complex z, int expt) { - double x, y, exp_x, scale1, scale2; + double c, exp_x, s, scale1, scale2, x, y; int ex_expt, half_expt; x = creal(z); @@ -105,6 +105,7 @@ half_expt = expt - half_expt; INSERT_WORDS(scale2, (0x3ff + half_expt) << 20, 0); - return (CMPLX(cos(y) * exp_x * scale1 * scale2, - sin(y) * exp_x * scale1 * scale2)); + sincos(y, &s, &c); + return (CMPLX(c * exp_x * scale1 * scale2, + s * exp_x * scale1 * scale2)); } --- /usr/src/lib/msun/src/k_expf.c 2019-02-23 07:45:03.881215000 -0800 +++ src/k_expf.c 2019-12-26 08:15:30.109818000 -0800 @@ -71,7 +71,7 @@ float complex __ldexp_cexpf(float complex z, int expt) { - float x, y, exp_x, scale1, scale2; + float c, exp_x, s, scale1, scale2, x, y; int ex_expt, half_expt; x = crealf(z); @@ -84,6 +84,7 @@ half_expt = expt - half_expt; SET_FLOAT_WORD(scale2, (0x7f + half_expt) << 23); - return (CMPLXF(cosf(y) * exp_x * scale1 * scale2, - sinf(y) * exp_x * scale1 * scale2)); + sincosf(y, &s, &c); + return (CMPLXF(c * exp_x * scale1 * scale2, + s * exp_x * scale1 * scale2)); } -- Steve From owner-freebsd-hackers@freebsd.org Sun Sep 20 07:41:44 2020 Return-Path: Delivered-To: freebsd-hackers@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 B983E3FEB58 for ; Sun, 20 Sep 2020 07:41:44 +0000 (UTC) (envelope-from weh@microsoft.com) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:febc::701]) (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 4BvKJl0k9Mz4CT6; Sun, 20 Sep 2020 07:41:42 +0000 (UTC) (envelope-from weh@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RKeJuD+T9uj7UkB5J+cW83aWORf4A59XHWMimv5WKUrsSt2iyiOHg1bCMpzt41IT3yNo62GNtt0vHnOn3XDKvZW3loYnmJW6MKlz99ZRLzERlAqP3YsBcZyxMCccyeGv1IgXzWViXAVd6cvtO+KpIXEVDYVjEul+rT+Qp3qnyTlRVrPzvldE2DLKd5AncweuTBUijGdNSjSnRfWRwNW0anEtShG2NAGJCsgvDV+8Jmm1WsajSaF2KBw2/N/ZVHR1eQZ+mQ7YGRDV2/s1toWzJroT8TFTuJutZuTE4hnvVL9ZHOVUbgABBt0ZLcYhfEcSKPgRbnq0W+K8ZvTHgLMjsA== 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=uCONOCOIXfB4KOy8uZGde43KvKuvtAx3vLe0avYEhEI=; b=Uv46fJYiuQXXnb3u3gALdlt9L/DRVv19trDVFWEpmu4RFEkWO5o/m+lDWnMNwKCocbMYVidIhGQpXoNk74hUH0q4hoI/eUJkaF/T0J2vHKQ7nXOdXLpp11nN6UFZ0X8Sp0+tVhQTBGMB3NuHlA9EsImO/eMkSfQFZNYWIEm2fkwFP02zHH/tGj29oLSBmJsu5yqf3kNhEAh7W5TeejiNzES2TbJb6IBsiCKoSP+Pk0VUOwbSfuM9CGYWr7ztUQQX5AwFSYIxAujp/ZxebhGA64Ao2FEP5kCWUjrRJNlY4WhKiMvq4E3Cg89FH9T+VVAlolERSS1CUDy7flgWnqVgog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none Received: from SG2P153MB0352.APCP153.PROD.OUTLOOK.COM (2603:1096:4:d4::23) by SG2P153MB0215.APCP153.PROD.OUTLOOK.COM (2603:1096:4:8c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.0; Sun, 20 Sep 2020 07:41:13 +0000 Received: from SG2P153MB0352.APCP153.PROD.OUTLOOK.COM ([fe80::e1d4:23b8:2c19:4745]) by SG2P153MB0352.APCP153.PROD.OUTLOOK.COM ([fe80::e1d4:23b8:2c19:4745%6]) with mapi id 15.20.3412.015; Sun, 20 Sep 2020 07:41:13 +0000 From: Wei Hu To: Konstantin Belousov , "avg@freebsd.org" CC: "freebsd-hackers@freebsd.org" Subject: RE: MSR accesses that slows down the hypervisor/host Thread-Topic: MSR accesses that slows down the hypervisor/host Thread-Index: AdaL9HYbtJyLPxf3TL+CSKzmJaxdTwAPNlyAACBa5AAAG7/AgAB/4PJA Date: Sun, 20 Sep 2020 07:41:12 +0000 Message-ID: References: <20200916135727.GO94807@kib.kiev.ua> <20200917183825.GU94807@kib.kiev.ua> In-Reply-To: <20200917183825.GU94807@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=0e8925c4-303a-47db-a31e-2880a55dc723; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-09-20T07:39:59Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-originating-ip: [116.233.42.161] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f6970a1e-55d8-4dd4-3845-08d85d388cd1 x-ms-traffictypediagnostic: SG2P153MB0215: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: U8k9DfWom5CSktXntYFuUr+UJwf+9auxtXwzL2bOQMaUI2gXEm0QTJHW1XeoeAW3yKyeNkzZvReJU8Z/vP+OGfzqJdqgk9u+NLb+rD4RkPHR7RSjtzlQe986VhpgC5l1llICFJdUFykM+RA6dei0wUZ3MH5eWhk70H3YMfGAv199Bu1ewVDACKk/QhSDwdu8Hnqaz2u1comdBkgwwIolgwtn7N89Rem412o37KgCe88j1nWD7/sy9qvcgESG+HscJsr9I+05BcUGZ/zTvkkAHU+jWJDESDHcxRmnBXcEWK8u7EezcLzJGfhl8M2GPPzbneQQX8Rf3mEbXJ0Y2FN4kMnXuSaNIEBALQZvgpUi5kRemislRQCR4GmLawg/Mw5vbb6lB0qk3MLkwpMRY5JU9iHaIve3HRlb2DGAII2rsIE2XJbDNDB8ojdYkNLzAjpc x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SG2P153MB0352.APCP153.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(136003)(346002)(366004)(376002)(4326008)(53546011)(478600001)(6506007)(76116006)(10290500003)(86362001)(186003)(7696005)(33656002)(8990500004)(66476007)(52536014)(64756008)(2906002)(66946007)(82950400001)(66556008)(82960400001)(9686003)(66446008)(8676002)(316002)(71200400001)(966005)(26005)(110136005)(8936002)(83380400001)(55016002)(5660300002)(83080400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 45OHpAV40pdifsVepmqpkTHXt0fnGnvyOjZKeh3XJgJ/zNGXV6Kh/5h/G/qJQXE+NAwj56GuD4HZScHLhJuDfC4T2cpL6smIpk2y4w9DeNvKgScgx0mnVwU0rH9inQJd+fNRCFhyEopyNcUtYkakAXFEXegpckRRc3x6kZL8b7o3xsm9EHGySba6j2+d5sIaYl02hOyItIRImODHPUj1ZEcxEnruFICCnJ9wO5UR6gALYn2HNV96wGcjY0irGY7+7qnPndO3sdmozZg4kpFT7Vz+98zhGwN9qKVF1eF0kbBuf37lS2LlATbKIvHyE9wwjrQczispFZMOYJCAtE/dBo5zMA6fAyw1dw6gTjxf8UJm8IazzwAlZPJK/DQGp0pXipl7oAFW+Y6gPI2Az0+r78T8Nd3z6cDgXO/MljWlf08FvYwtjn/b+mJROI86tvoT8SOplftJOTzOk6ej1lkbW1MqxD1tUTMbQd2x3CZmBVpB4roFJFCtxZmTGz9FeooQ9t+sZasfD/y/5fnplZcmcZZBUWOOuxiuMJ67V1nA5ZVqQTd7Hm6AHaxDfzLjo/NwwZb7/GFePqaVk+/gXyRes87HpaOed6fPmgeAUY2oFklAK0HTCXsWThAnenc7biwPqO0mT6hSs6BdMGMxcLt/xA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SG2P153MB0352.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: f6970a1e-55d8-4dd4-3845-08d85d388cd1 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2020 07:41:13.0551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aHWoZQR9WKqL0F27fUepUQUfOIicHMYlJULivGl4Y+nPbZ+q9P05nZFJ7ZMsQOTjhtjTecnbchtE//Y3FWvOTQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2P153MB0215 X-Rspamd-Queue-Id: 4BvKJl0k9Mz4CT6 X-Spamd-Bar: ---------- X-Spamd-Result: default: False [-10.20 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.006]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.02)[-1.021]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; NEURAL_HAM_SHORT(-1.17)[-1.174]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 07:41:44 -0000 > > > From: Konstantin Belousov > > > Sent: Wednesday, September 16, 2020 9:57 PM > > > To: Wei Hu > > > Cc: freebsd-hackers@freebsd.org > > > Subject: Re: MSR accesses that slows down the hypervisor/host > > > > > > Where do you see accesses to MSR_LS_CFG ? I can only find > > > manipulations of that MSR in init_amd(), and then it is all under > > > check that we are not virtualized. > > > > > Yes, it is only accessed in init_amd() at boot time. So it is less > > concerned. MSR_AMDK8_IPM is accessed in cpu_idle() all the time, so it = is > the key place to optimize. > > > > > For MSR_AMDK8_IPM access in cpu_idle(), it seems that the workaround > > > was applied too wide. It might be that we do not need to do it on > > > recent CPUs, but I need to spent more time looking at datasheets to > confirm/deny. > > > > > > But, do you (hypervisor) indeed allow guest to initiate C1 or deeper = idle > state ? > > > If not, perhaps as the first measure, we can avoid manipulating > > > MSR_AMDK8_IPM under hypervisor at all. > > > > You are right a guest cannot initiate C1 or deeper idle state when runn= ing on > Hyper-V. > > So skipping the read of MSR_AMDK8_IPM when running under this > > hypervisor would Be a viable solution. >=20 > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Frevie= ws > .freebsd.org%2FD26470&data=3D02%7C01%7Cweh%40microsoft.com%7C8 > 7f5f82583ee428f49c108d85b38e9c3%7C72f988bf86f141af91ab2d7cd011db4 > 7%7C1%7C0%7C637359647283571535&sdata=3DJdKxHO1sM2InD7Eo793FF > RIpj5AQmowcc%2BLGW19dlH4%3D&reserved=3D0 Thanks for the quick response. I will review the change and do some tests o= n Hyper-V. Wei From owner-freebsd-hackers@freebsd.org Sun Sep 20 08:16:58 2020 Return-Path: Delivered-To: freebsd-hackers@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 DE01B3FFD4A for ; Sun, 20 Sep 2020 08:16:58 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvL5P5X7Xz4F6p for ; Sun, 20 Sep 2020 08:16:57 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 08K8GqMn056052 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Sep 2020 10:16:52 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1600589812; bh=oo/dWKqraV3lmEKnRUOYGYuBYOOvrwm1wG7lQ6ljX0U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cn1pJz+f5QVNM8Kwlu7Mz2nLGxpGSE+hka8hcQ6tCnYj0EzxV8JJBAtcCcwRFs22S rouW65R4ZZBGX4gRF+2TYwgUWydB6cS/JxEiip1ljvXwpMFH2XxEgeAbWzQ/2NYZyN q1LpPpil0bDmMbaaRKObDT9WL0WAmr5q/3jTI8a4= Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.16.1/8.16.1/Submit) with ESMTP id 08K8Gq3n056049; Sun, 20 Sep 2020 10:16:52 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Sun, 20 Sep 2020 10:16:52 +0200 (CEST) From: Wojciech Puchar To: Wojciech Puchar cc: freebsd-hackers@freebsd.org Subject: Re: portsnap problem In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4BvL5P5X7Xz4F6p X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=fail (headers rsa verify failed) header.d=puchar.net header.s=default header.b=cn1pJz+f; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-1.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.026]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_REJECT(1.00)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[puchar.net]; NEURAL_HAM_LONG(-1.04)[-1.037]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:-]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.43)[-0.428]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 08:16:58 -0000 sorry my fault. everything is ok. please ignore question On Sat, 19 Sep 2020, Wojciech Puchar wrote: > i have up to day portsnap database on one host in /var/db/portsnap > > portsnap update works correctly > > i exported it over NFS > /var/db/portsnap -ro -network 10/8 > > > and mounted on another computer > > 10.1.0.1:/var/db/portsnap /var/db/portsnap nfs ro,late 0 0 > > > and portsnap doesn't work > > # portsnap update > No snapshot available. Try running > # portsnap fetch > > > what's more is needed that is not in /var/db/portsnap? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@freebsd.org Sun Sep 20 15:45:46 2020 Return-Path: Delivered-To: freebsd-hackers@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 F2B1E3E5D83 for ; Sun, 20 Sep 2020 15:45:46 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvX3G1WtTz3SvD for ; Sun, 20 Sep 2020 15:45:45 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f182.google.com with SMTP id m7so13994707oie.0 for ; Sun, 20 Sep 2020 08:45:45 -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:from:date:message-id:subject:to; bh=6n+5NjqidHYV7vdrnmZmZT6qehd7oJZpT0cmsV8w9m0=; b=m7pACWjcoavVUSgfn76eVTmNhLzc1JfbUk6x9hBwHlqMdnHI+uNtdo7lUXZk2uVoi8 E64qKVGbmivgFJAQYmZows1LZpw/Ya1AKq0m2SmtvcPoHuY/E/7yAuHdPPyzt6RJGafc dNdXSorv5MiP3XbWwetmlDLs4gXOem1nj/dp/nE7kIZLZRNpm4236ELqcU6xgP7eWFtH 5YXgkha5NiYowJDVghKALHc2+S5JqUad9PqkO8LdQZBgzGZhqHxykWNjKxayhbhSscAw qmxI+mA85PQpXC8DgZIvEfvO+s6CfodFHKPAt3TL9KxBgSdLNplYYBYw+HFMG7BLyKoN q/SA== X-Gm-Message-State: AOAM533fLlJuCqTIQz41ggSs1+bWFS0u2V50NW0dWlRzXihKrFAa3OTk zpePdB1uSmpn1zxWI2JUAaJ0YGyTgh4YUfHkq6JkqqQU X-Google-Smtp-Source: ABdhPJztz1vrBIHm7dGxVMhFu8K2OY9r4Vmy54tRPBM/U8c7OgDVqtY2OMzTUDkVBUHOSxUmRl7/kbfLodkB5SK2pUE= X-Received: by 2002:aca:45c2:: with SMTP id s185mr15862582oia.57.1600616744898; Sun, 20 Sep 2020 08:45:44 -0700 (PDT) MIME-Version: 1.0 From: Alan Somers Date: Sun, 20 Sep 2020 09:45:34 -0600 Message-ID: Subject: RFC: copy_file_range(3) To: FreeBSD Hackers X-Rspamd-Queue-Id: 4BvX3G1WtTz3SvD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.182 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.45 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.90)[-0.901]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.56)[-0.565]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.182:from]; NEURAL_HAM_MEDIUM(-0.99)[-0.985]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.182:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers]; TO_DOM_EQ_FROM_DOM(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 15:45:47 -0000 copy_file_range(2) is nifty, but it has a few sharp edges: 1) Certain file systems don't support it, necessitating a write/read based fallback 2) It doesn't handle sparse files as well as SEEK_HOLE/SEEK_DATA 3) It's slightly tricky to both efficiently deal with holes and also promptly respond to signals These problems aren't terribly hard, but it seems to me like most applications that use copy_file_range would share the exact same solutions. In particular, I'm thinking about cp(1), dd(1), and install(8). Those three could benefit from sharing a userland wrapper that handles the above problems. Should we add such a wrapper to libc? If so, what should it be called, and should it be public or just private to /usr/src ? -Alan From owner-freebsd-hackers@freebsd.org Sun Sep 20 15:58:11 2020 Return-Path: Delivered-To: freebsd-hackers@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 E75CB3E6009 for ; Sun, 20 Sep 2020 15:58:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660074.outbound.protection.outlook.com [40.107.66.74]) (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 4BvXKZ63Fbz3T4h; Sun, 20 Sep 2020 15:58:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lZ1ZRI3eCMSQnkDC7ZHUE1ZP3Us1xL49EUExKJY6StQ882xKulK31sVIgGDKm/jKJIcRPKjRi04Y05dKen02a4YzsPbtyNiUjAlF7bGecC1we6RfcpOh7KKrVTEiVdv+jOBriTkNMuDAPbgWrzmB0jsRczQEvdysdeIGpFqtlTyY5RcqKV+ti8sOyVsiVjJnki60yvQ5tNeB7nfSsNRbPA3ShlweD+u7EUzRbtfo4Kwcfnsowoa3Kg1KC5h0YOs+1fvovGhppDORCbBDbbe2m6Oz05Xb8GcX4HvXh12/R+1NaVoI3XZHgMM0iW9lDxIiM+8cSah28bE1gB3DlMtDNA== 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=dkP5eT9t6Df7vVO9XfUKm5oSVdN4vwv5hBoHmimNotU=; b=HNI0awq5Gv3KdXxr01Pqrq+NfaGG2j7nXBk2n2CpMcml6rv8cKr6VCSTMlsp5dQQsUsVUC2LmR2F2N5lZEYTpp97hmapfQa9UBpiMlub/6rReYUtMKm7pai1LLkcVaoJaU0nsMudXxw0VYPsp6LaszMcAL4FoiNVRDuct73oSWl+p4w6XCDm+pMx+vVqD3ygeufp/Pk1nLbQ1fO4X+1wQ4nq+8t3FyBlc+Q0ugZOPBGeJBlE9lL4JtJDVEFU08vmr2gzF61Ut3+JgXl7kmm1ULJNYsWnqTQ3tXVsze92mFE49yWnBI7Q205us10b6VVAEN+0f9qaVzID3lGhxFc1LQ== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dkP5eT9t6Df7vVO9XfUKm5oSVdN4vwv5hBoHmimNotU=; b=VtkPQmax1dF/toqtvjFJo7a+Sb767KXz0QdE/txGMoGaLOcdKgCow0qzvyTv9xVAv3HiE1cQn07+OzS5V0/+M3JRUP+AhdDDi5Dd08PERj/qEzhO/Ri37lwH1kWLDzipAux8pWfR+tmqZfIn0D17DZ9vh2puST6PAihkW3f/6uVjvXtmmmb/LeXGNO9p+vx21mxPYTPkeDPM8nhVJB74GCfECGQMXQp1eZP5oI+sH61kdeWIiDJemVvOC9he5X2rrBD40QWM1+rqRNymFJa7bdtgirDMIqJsc3Jd/BExkXNu4UZ2YIWGIJpNuQm/FYsDtBjRoEIN48Sx8VgAPW2KmQ== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTBPR01MB2895.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:17::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.11; Sun, 20 Sep 2020 15:58:09 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3391.014; Sun, 20 Sep 2020 15:58:09 +0000 From: Rick Macklem To: Alan Somers , FreeBSD Hackers Subject: Re: RFC: copy_file_range(3) Thread-Topic: RFC: copy_file_range(3) Thread-Index: AQHWj2Uep8NVOqCTP0KuS7h/nlgLPqlxrARq Date: Sun, 20 Sep 2020 15:58:09 +0000 Message-ID: References: In-Reply-To: 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: f85784ff-5220-4128-4241-08d85d7df86f x-ms-traffictypediagnostic: YTBPR01MB2895: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: R3ItNwVNpo3bJHgoqQIvxXNSVlbTHf8CBhW4FEINUU9sY3DagrwTTODtTk0TPCikaJGvq/OKvOj+Na741+WDcg1LzlZZPzq1VtiJ3tnSqo2hK79NQ1bbm7syTajCuHi4RTPOUAAULGAIZtKpykWdG4fYd1frK5btUh8sCq/JIzUo7cl0D1pwzB+OdujGSAbuSOs8ZCGHRkJFNfx1GevoH7xFisOgebi8WhbG+dfcChGxmkJ0bMYEfL9OO1pB5ZqVoRo3D4THAv5WVEQa86FTZUvxMTBVCa+XbzyH+Qq6NGJUwexXUDNBAcvaPhXT5lQt18vLgEBZcesgxOlEk4r4Kvs8p3tCX/0Ksq0TcBQEmUP9gI41rdc4TMWHl//7a3osqYYW01yyG/MnTR0gem+WNA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(39850400004)(366004)(346002)(376002)(136003)(786003)(316002)(76116006)(7696005)(86362001)(8676002)(33656002)(8936002)(55016002)(91956017)(2906002)(186003)(9686003)(5660300002)(52536014)(66946007)(110136005)(64756008)(6506007)(66446008)(71200400001)(450100002)(66476007)(66556008)(966005)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: RSpaFlZRay9OS6KspLoCOY4xG6lSfb7vlKHcqBds2x98YdVPFEj4Ml428hgfckIfDzswvvt+kOhZ4LRkz6h5rle7gcnEXnbLYGVCCN1BFUj2MioiNViRGC5J22g8/Ya5JffirbFDXpEgAAw3YlJ3iC6S1p6dYRQwJvzzF9IOcJM1/oFO0U5jToyUTkpX7zzh//O9xQD/rlLVPebdklHT3ic8rHV5o3MWjVXi2k/kJ5V6RTrgn+tl9s0/PSTT40Ce2jRW9SAr7LuBnNDVYoAk5GtfSmSH8w/c+X9QNUHLr+xutvBgGKSu+3SI5kM8oeRrsYniGofC04LOLuW+d4OxgvBpurfrtnkt0kcGyD7hOWM0LR3XU+mApxfYD5HZeGF7zgnivUlW7YRZ460fVX8+FptlInsO+TLtSyxs7+P3KcNNMETiz4EXVF6xaxxyg6fJVWri4OONJCPHWUrZuo0zsubcwUbI+vPtSEw8W/643SILjBqIEGxethB3jZggnQs3GeDQW+iK+8YtBtnr9nYLjUrETnOuCKqMtmWeiKONbzs1QJc5hgjLkNIwlL1SuZevVQUn3ugTMkvwrMAmjsN+LP/tQa0pvS9kL4p941llXCgakuyAFCD/IuL2u4bvsfF5HPbD+OX2QgFWYDzz4Ni8dXvwqHW8p5UD89CkfyuVx1wUnf0KjuseCn8xr8N16HWGIhvzKBFe7Lj2VbdH3ZxbMw== x-ms-exchange-transport-forked: True 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: f85784ff-5220-4128-4241-08d85d7df86f X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2020 15:58:09.2211 (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: yAZiLoH3ng6mVqXIg18xd3Uev0ZJifRWVB8X9UVYKtbfphCGeOoV4LelIFSLi2DjV0Ll5FMzAeGLguX/unodtA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB2895 X-Rspamd-Queue-Id: 4BvXKZ63Fbz3T4h X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=VtkPQmax; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.74 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.03)[-1.030]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.03)[-1.034]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.74:from]; NEURAL_HAM_SHORT(-0.84)[-0.835]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.74:from] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 15:58:12 -0000 Alan Somers wrote:=0A= >copy_file_range(2) is nifty, but it has a few sharp edges:=0A= >1) Certain file systems don't support it, necessitating a write/read based= =0A= >fallback=0A= >2) It doesn't handle sparse files as well as SEEK_HOLE/SEEK_DATA=0A= >3) It's slightly tricky to both efficiently deal with holes and also=0A= >promptly respond to signals=0A= >=0A= >These problems aren't terribly hard, but it seems to me like most=0A= >applications that use copy_file_range would share the exact same=0A= >solutions. In particular, I'm thinking about cp(1), dd(1), and=0A= >install(8). Those three could benefit from sharing a userland wrapper tha= t=0A= >handles the above problems.=0A= >=0A= >Should we add such a wrapper to libc? If so, what should it be called, an= d=0A= >should it be public or just private to /usr/src ?=0A= There has been a discussion on src-committers which I suggested should=0A= be taken to a public mailing list.=0A= =0A= The basic question is...=0A= Whether or not the copy_file_range(2) syscall should be compatible with=0A= the Linux one.=0A= When I did the syscall, I tried to make it Linux-compatible, arguing that= =0A= Linux is now a de-facto standard.=0A= The Linux syscall only works on regular files, which is why Alan's patch fo= r=0A= cp required a "fallback to the old way" for VCHR files like /dev/null.=0A= =0A= He is considering a wrapper in libc to provide FreeBSD specific semantics,= =0A= which I have no problem with, so long as the naming and man page make=0A= it clear that it is not compatible with the Linux syscall.=0A= (Personally, I'd prefer a wrapper in libc to making the actual syscall non-= Linux=0A= compatible, but that is just mho.)=0A= =0A= Hopefully this helps clarify what Alan is asking, rick=0A= =0A= -Alan=0A= _______________________________________________=0A= freebsd-hackers@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A= To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= =0A= =0A= From owner-freebsd-hackers@freebsd.org Sun Sep 20 16:04:10 2020 Return-Path: Delivered-To: freebsd-hackers@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 AEF763E6A0E for ; Sun, 20 Sep 2020 16:04:10 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvXST598Mz3V24 for ; Sun, 20 Sep 2020 16:04:09 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f48.google.com with SMTP id n61so10139138ota.10 for ; Sun, 20 Sep 2020 09:04:09 -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; bh=N7a7M4d7Cq3PaaABjt3bMm+CTTTplS5I+/P0bqN0IGc=; b=NgJVA2znW+qOhOUgoMTfhct07hfc8jLd81kfti8qw+yFokN5Omd/CmODZnAvaRIg8k A588XfmK7yqpvSH0OxWEBFivXWTL/CVvWIP1jUSi8dQNnsBFaoAs5CbGIq0Z4ceMNOKY EO5uCEkKDP8B2CcbrlzUl6MDn4LHU0y6+FQGVg3Gnyay5DjhP4Qwr/jbqA2k3btMjYf2 wlzMDIRhQlb2rP64S3eq+VCYMi2DTekFruFqZFwy9eix+lcUeBbVUfptseJBUcicMxlM u/AoVeF7RWer236i9XBqgjh75wyToEKlxuRefzHPFpv777ogDDqvIQS9DJaXtTbfC2xf liOw== X-Gm-Message-State: AOAM5309h0WKD7oEeMgyzvDyg1WudBMV3iwK9zOsC15lEaEd/v0/KSUD JeLD8rUHRK+S8mw3iPWNy2mNbRD7a8GeLb6lsuo= X-Google-Smtp-Source: ABdhPJxqNX+Km1WvwI0eXAYYS/X8XnmMZCbrBUDx6kfqXpJPhLt0Jx4fPRgQ/O/MnbDXhfeFZNIZsRMGaAxtIfUbk30= X-Received: by 2002:a05:6830:1286:: with SMTP id z6mr27893919otp.291.1600617848599; Sun, 20 Sep 2020 09:04:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sun, 20 Sep 2020 10:03:57 -0600 Message-ID: Subject: Re: RFC: copy_file_range(3) To: Rick Macklem Cc: FreeBSD Hackers X-Rspamd-Queue-Id: 4BvXST598Mz3V24 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.48 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.89 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.48:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.08)[-1.079]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.79)[-0.791]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.48:from]; NEURAL_HAM_MEDIUM(-1.01)[-1.015]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 16:04:10 -0000 On Sun, Sep 20, 2020 at 9:58 AM Rick Macklem wrote: > Alan Somers wrote: > >copy_file_range(2) is nifty, but it has a few sharp edges: > >1) Certain file systems don't support it, necessitating a write/read based > >fallback > >2) It doesn't handle sparse files as well as SEEK_HOLE/SEEK_DATA > >3) It's slightly tricky to both efficiently deal with holes and also > >promptly respond to signals > > > >These problems aren't terribly hard, but it seems to me like most > >applications that use copy_file_range would share the exact same > >solutions. In particular, I'm thinking about cp(1), dd(1), and > >install(8). Those three could benefit from sharing a userland wrapper > that > >handles the above problems. > > > >Should we add such a wrapper to libc? If so, what should it be called, > and > >should it be public or just private to /usr/src ? > There has been a discussion on src-committers which I suggested should > be taken to a public mailing list. > > The basic question is... > Whether or not the copy_file_range(2) syscall should be compatible with > the Linux one. > When I did the syscall, I tried to make it Linux-compatible, arguing that > Linux is now a de-facto standard. > The Linux syscall only works on regular files, which is why Alan's patch > for > cp required a "fallback to the old way" for VCHR files like /dev/null. > > He is considering a wrapper in libc to provide FreeBSD specific semantics, > which I have no problem with, so long as the naming and man page make > it clear that it is not compatible with the Linux syscall. > (Personally, I'd prefer a wrapper in libc to making the actual syscall > non-Linux > compatible, but that is just mho.) > > Hopefully this helps clarify what Alan is asking, rick > I don't think the two questions are equivalent. I think that copy_file_range(2) ought to work on character devices. Separately, even it does, I think a userland wrapper would still be useful. It would still be able to handle sparse files more efficiently than the kernel-based vn_generic_copy_file_range. -Alan From owner-freebsd-hackers@freebsd.org Sun Sep 20 21:47:09 2020 Return-Path: Delivered-To: freebsd-hackers@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 E66B53F2E81 for ; Sun, 20 Sep 2020 21:47:09 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [138.201.35.217]) (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 4Bvh4D3DYFz4Zr1 for ; Sun, 20 Sep 2020 21:47:08 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest-mbp.fritz.box (200116b86457cc00411f9dfb593e27cd.dip.versatel-1u1.de [IPv6:2001:16b8:6457:cc00:411f:9dfb:593e:27cd]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 29CB620227 for ; Sun, 20 Sep 2020 21:46:58 +0000 (UTC) Subject: Re: ASPEED video driver To: freebsd-hackers@freebsd.org References: <8851FC7F-979D-4CDC-8513-CE893B2EF269@dons.net.au> From: Crest Message-ID: <8b15ca21-07d1-7eb1-4d99-3654af585052@rlwinm.de> Date: Sun, 20 Sep 2020 23:46:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <8851FC7F-979D-4CDC-8513-CE893B2EF269@dons.net.au> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4Bvh4D3DYFz4Zr1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 138.201.35.217 as permitted sender) smtp.mailfrom=crest@rlwinm.de X-Spamd-Result: default: False [-2.43 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.97)[-0.967]; ARC_NA(0.00)[]; NEURAL_HAM_SHORT(-0.41)[-0.414]; DMARC_NA(0.00)[rlwinm.de]; NEURAL_HAM_MEDIUM(-0.75)[-0.751]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:138.201.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers]; RECEIVED_SPAMHAUS_PBL(0.00)[2001:16b8:6457:cc00:411f:9dfb:593e:27cd:received] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 21:47:10 -0000 On 07.09.20 05:32, O'Connor, Daniel via freebsd-hackers wrote: > Hi, > Has anyone had success with the ASPEED Xorg driver? I have tried several versions (in ports, from ASPEED directly, from freedesktop.org etc) and they all hang trying to read DRAM information in ASTGetDRAMInfo. I am running FreeBSD 12 on a Supermicro X11SSH-F. > > > The hang is here: > do { > ; > } while (*(volatile ULONG *) (pAST->MMIOVirtualAddr + 0x10000) != 0x01); > > I patched it to use some hard coded values I extracted from an old system where it worked and it does run but the performance is quite terrible. > > I've also tried scfb (performance is so so but it's stuck and 1024x768) and VESA (runs at 1920x1080 but the performance is intolerable). > > I'm not expecting mind blowing performance but even the best performing option above is quite painful to use. These systems are mostly unattended but the bad performance does make the setup and test during installation quite painful. > > Performance used to be tolerable but it seems to have gotten significantly worse in newer BIOS versions. > > For now we are putting passively cooled GT710s in them but it would be nice to fix it properly. > > I note that Linux has a DRM driver for these https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/ast > > However I'm not sure how that integrates with X.. If Linux doesn't actually use the Xorg driver then I suppose that would explain why it's rotted and useless. > > If that is the case, does anyone know difficult it would be to port the Linux DRM driver? > > I did try contacting ASPEED and Supermicro but they pointed the finger at each other and then blamed FreeBSD so I'm a bit stuck. > > Thanks. I have no solution for the question you've asked, but I may have a solution for your problem. Over the years I've found the different IPMI KVM implementations terrible to use (slow to update, ridiculous input lag, keyboard layout fuck ups, etc.). Instead I prefer to use the IPMI Serial over LAN interface to install fresh systems avoiding the trouble of emulating a keyboard (and mouse) and capturing the video output. On most servers you can interrupt the boatloader via the serial connection and enable dual console operation in FreeBSD. Some of the buggier IPMI implementations work better with *only* a serial console enabled. This example should work for most modern x64 server boards (with minimal changes) boot_multicons="YES" # Enable multi console support boot_serial="YES" # Enable serial output console="comconsole,vidconsole" # On UEFI systems try efi instead comconsole_speed="115200" # Most boards default to 115200 baud instead of the 9600 FreeBSD uses for legacy reasons # comconsole_port="0x2f8" # If the Serial over LAN is mapped to COM2, check dmesg | grep uart Sorry if this reads like a "you're holding it wrong" kind of answer, but I haven't had much success with IPMI keyboard and video redirection over the years. From owner-freebsd-hackers@freebsd.org Sun Sep 20 23:14:57 2020 Return-Path: Delivered-To: freebsd-hackers@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 C56683F4C6C for ; Sun, 20 Sep 2020 23:14:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0612.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::612]) (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 4Bvk1X6rbSz4gVJ; Sun, 20 Sep 2020 23:14:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HalHKprSZkfYEj1+L4H87MvDW3kxi7ayStTnMDwe3R+EqlR54YlJx+BHVbEXvZXv6NUUgvxuLu2LRaWrR+3Wyz3l5XJLtIvCKXq3ax+RWdfQZj60svAqmWYH9M6N2rHUhM5ogonDLXu8tUMMvNzW88N3PYvp2ArCsuh73ESPbh4ofAA+epLSo9AcQmryfiFvmj1SD4sjsrCf6e09FNM+gRlCnreco8hto4urnbI4b63PxDlBAgpFK6aFQtd3FlndFMxKvlPekuLqqpm6ya+LH5ecp6mjika9Zy6PBvlVEL9vyteyybQC5P8ro0kezAzBc5udpzm6fvJ3hRnYUqFrlw== 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=WAP9mnIWmDjdEoVgWSsKP27Euw60nSCef0fYFjydFJY=; b=kv7mEKjiASk490rGuVW0gWXHsOGuM6qnr+3f5Moxak/aTjekBkj0iwR5ZeWD+OphT+x+j+GS7iauEGPVJuFr6ePcTCjgtllRUiXVF/Fc4bwr6tkbe2OpYZTOwjyvhUdvol3+NNSjxzH5avXr8JyZF4XNnH/m3xfHGoiALeUd+ImgWw4FZcnErocnW5yfyyLI2iHF/I6rhHHwnfcPpl7uQN/VRe1/V7Yfo1QpNQMtb9kXz6erHQgzBaUdxSNaXlp+jg0Wp5y4zvDbZ/okhPMuFavmBEKpTcgQIz+B9cPl3r9E6qZwD73gGxpjyDA7zHoNKJoBo92y4GB1EIomhU/sPg== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WAP9mnIWmDjdEoVgWSsKP27Euw60nSCef0fYFjydFJY=; b=hLbf7ZZwnJnaSxiCVgIF3u5u/XDKv2XpckOIG/H4nhxj+BB2aHu/viWlk5qXIjEWGPHHpWY6729DbmtYWpizkmsjLc9iBDIVzknhl3F9bxYuO2JFzqi5TLH6kmustuOuWjS25yu4HxM6hTM3poubOfQdTaG2wqN68Jt2bncnsobRjus1yHjeOqsdBcWqyPEGwOaotSBndDqLVmbGtHE2je+nrgOZens3ga8ME3OCoBzEHCYLGJtSH5Kr6eimyanjG+uHvWz2437oqYu9EogUt8w3b1WketaKpqhI/mv2Lnkaczg9cUDd9IAXkW0nxrNtwoXP3Ag7DFLl3eMtv3COwg== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YT1PR01MB2938.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:e::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.11; Sun, 20 Sep 2020 23:14:55 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3391.024; Sun, 20 Sep 2020 23:14:55 +0000 From: Rick Macklem To: Alan Somers CC: FreeBSD Hackers Subject: Re: RFC: copy_file_range(3) Thread-Topic: RFC: copy_file_range(3) Thread-Index: AQHWj2Uep8NVOqCTP0KuS7h/nlgLPqlxrARqgAAEfICAAHAflQ== Date: Sun, 20 Sep 2020 23:14:55 +0000 Message-ID: References: , In-Reply-To: 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: d594c3d4-076a-4852-c6a1-08d85dbafc52 x-ms-traffictypediagnostic: YT1PR01MB2938: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d5vP8Nn71Xzm2Z+a/O4OWtSFyiR8NhuGTjbdqVK16YZr/9vw42txvGXkC5KDjKP0jPQtIhe+Dtek50aB85YwO4z/Cqfw+hGQeM8A7GOY+yEyhncVlVYrPMkv9fPjXDyP/TBNP7aq3JFzheNiD00KzR6aj+Ctf1l8Eti+IQbB1m2yu9Qnru/B+be9plyTkB7hd0VQMONa2g8zvc9neEeqCmdc5BsNRYZofsGq8bgaYIj/6E0nnw/vjXtJjiiBwI0kpUp8EAWfXP8pbk6GxKIqP2E79kAblEFo/+2rsN9xXHjnxkADJ2v2vLUtxbRZMQBBN9z49jnpVo9M4LkdkuZkSw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(136003)(39850400004)(396003)(5660300002)(450100002)(8676002)(66946007)(86362001)(66446008)(52536014)(55016002)(7696005)(76116006)(4326008)(71200400001)(64756008)(66476007)(91956017)(66556008)(2906002)(83380400001)(6506007)(9686003)(6916009)(478600001)(786003)(8936002)(33656002)(186003)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 4iCYSF6rfn75O+xMRJ/SkrkXDg5dk3J92uSCj3JDGK8oAUFDa0S+HGZgqsUoshV+tfgJbyWyXOuv66dM2zrGhgEhpvbgDYKyliizViQYr49RKG2jwLVAOtrcTsEBRxsW32pFHqMsW6Or4C4zplHlF9gkN6CZF0xtFAP0yVllSrlS4KG44X9HHd1kI2BwfGg9ZjmrxkqvD++buJUqo1ZrFw/IaANKwhyAjOrnywWzIW866WI2JFMQo/TzetdVb7mAghGn1TZXvzdHgiejwdHVE44Bb4qJZdDkEuLe+FXPx8WjSoF0R1yvbT7g76wjHlwDy6N35BtB67jIypEtFCeCD42XZrIEE0C+l8UiZvca2Ejw9YbLt0rEcCX1+mw12sJdwa93mdkKLNezl1dQGTz0/odikkf4a3FxuRtsdDy/fRjrcOuHnQDXCW6ML4ZmN/nNSuQAZtcS812idqvSYCWTljrTpFnmNwVoiZE4ZhvF0GwR7gcR3Dx5mzqhNkH2j22hojjAQjJ6OBhTAgONElpR4TY0bxDtNYj6ECVB5Jk9afjBwUhUCTC24OfaktITmb1CfyP5O+MZJTA74uN2jNQQ6Hb/9OqEyFw9pKhoNbTb/H0kb+gcRGbuC9wCG8aCPNmoIQ3vaj5cZtUNLhtPl1gplna54Hh1HuzaeQOM8CVNGNsczELvGK2pg3QKjMV1lZVKrdesBEfafE4NfB6IUMdHxg== x-ms-exchange-transport-forked: True 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d594c3d4-076a-4852-c6a1-08d85dbafc52 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2020 23:14:55.0799 (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: qwtQDDiEcQ1oTk+efOcjQU8JNtwpklFmFSKzfzST9HKo6mN6io4E+gAp9JcSmEF0GJt6Lz/xhBSu0nMwJh/P9Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB2938 X-Rspamd-Queue-Id: 4Bvk1X6rbSz4gVJ X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=hLbf7ZZw; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5d::612 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.21 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.02)[-1.022]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.20)[-1.195]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 23:14:57 -0000 Alan Somers wrote:=0A= >On Sun, Sep 20, 2020 at 9:58 AM Rick Macklem > wrote:=0A= >>Alan Somers wrote:=0A= >>>copy_file_range(2) is nifty, but it has a few sharp edges:=0A= >>>1) Certain file systems don't support it, necessitating a write/read bas= ed=0A= >>>fallback=0A= >>>2) It doesn't handle sparse files as well as SEEK_HOLE/SEEK_DATA=0A= >>>3) It's slightly tricky to both efficiently deal with holes and also=0A= >>>promptly respond to signals=0A= >>>=0A= >>>These problems aren't terribly hard, but it seems to me like most=0A= >>>applications that use copy_file_range would share the exact same=0A= >>>solutions. In particular, I'm thinking about cp(1), dd(1), and=0A= >>>install(8). Those three could benefit from sharing a userland wrapper t= hat=0A= >>>handles the above problems.=0A= >>>=0A= >>>Should we add such a wrapper to libc? If so, what should it be called, = and=0A= >>>should it be public or just private to /usr/src ?=0A= >>There has been a discussion on src-committers which I suggested should=0A= >>be taken to a public mailing list.=0A= >>=0A= >>The basic question is...=0A= >>Whether or not the copy_file_range(2) syscall should be compatible with= =0A= >>the Linux one.=0A= >>When I did the syscall, I tried to make it Linux-compatible, arguing that= =0A= >>Linux is now a de-facto standard.=0A= >>The Linux syscall only works on regular files, which is why Alan's patch = for=0A= >>cp required a "fallback to the old way" for VCHR files like /dev/null.=0A= >>=0A= >>He is considering a wrapper in libc to provide FreeBSD specific semantics= ,=0A= >>which I have no problem with, so long as the naming and man page make=0A= >>it clear that it is not compatible with the Linux syscall.=0A= >>(Personally, I'd prefer a wrapper in libc to making the actual syscall no= n-Linux=0A= >> compatible, but that is just mho.)=0A= >>=0A= >>Hopefully this helps clarify what Alan is asking, rick=0A= >>=0A= >>I don't think the two questions are equivalent. I think that copy_file_r= ange(2) >>ought to work on character devices. Separately, even it does, I = think a userland >>wrapper would still be useful. It would still be able t= o handle sparse files more >>efficiently than the kernel-based vn_generic_c= opy_file_range.=0A= I saw this also stated in your #2 above, but wonder why you think a wrapper= =0A= would handle holes more efficiently.=0A= vn_generic_copy_file_range() does look for holes via SEEK_DATA/SEEK_HOLE=0A= just like a wrapper would and retains them as far as possible. It also look= s=0A= for blocks of all zero bytes for file systems that do not support SEEK_DATA= /=0A= SEEK_HOLE (like NFS versions prior to 4.2) and creates holes for these in= =0A= the output file.=0A= --> The only cases that I am aware of where the holes are not retained are:= =0A= - When the min holesize for the output file is larger than that of the= =0A= input file.=0A= - When the hole straddles the byte range specified for the syscall.=0A= (Or when the hole straddles two copy_file_range(2) syscalls, if you= =0A= prefer.)=0A= =0A= If you are copying the entire file and do not care how long the syscall=0A= takes (which also implies how long it will take for a termination signal=0A= like C to be handled), the most efficient usage is to specify=0A= a "len" argument equal to UINT64_MAX.=0A= --> This will usually copy the whole file in one gulp, although it is not= =0A= guaranteed to copy everything, given the Linux semantics definition= =0A= of it (an NFSv4.2 server can simply choose to copy less, for example= ).=0A= --> This allows the kernel to use whatever block size works efficien= tly=0A= and does not require an allocation of a large userspace buffer= for=0A= the date, nor that the data be copied to/from userspace.=0A= =0A= The problem with doing the whole file in one gulp are:=0A= - A large file can take quite a while and any signal won't be processed unt= il=0A= the gulp is done.=0A= --> If you wrote a program that allocated a 100Gbyte buffer and then=0A= copied a file using read(2)/write(2) with a size of 100Gbytes in a = loop,=0A= you'd end up with the same result.=0A= - As kib@ noted, if the input file never reports EOF (as /dev/zero does),= =0A= then the "one gulp" wouldn't end until storage is exhausted on the=0A= output file(s) device and C wouldn't stop it (since it is one b= ig=0A= syscall).=0A= --> As such, I suggested that, if the syscall is extended to allow VCH= R,=0A= that the "len" argument be clipped at "K Mbytes" for that case t= o=0A= avoid filling the storage device before being able to C ou= t=0A= of it, for this case.=0A= I suppose the answer for #3 is...=0A= - smaller "len" allows for quicker response to signals=0A= but=0A= - smaller "len" results in less efficient use of the syscall.=0A= =0A= Your patch for "cp" seemed fine, but used a small "len" and, as such,=0A= made the use of copy_file_range(2) less efficient.=0A= =0A= All I see the wrapper dong is handling the VCHR case (if the syscall remain= s=0A= as it is now and returns EINVAL to be compatible with Linux) and making=0A= some rather arbitrary choice w.r.t. how big "len" should be.=0A= --> Choosing an appropriate "len" might better be left to the specific use= =0A= case, I think?=0A= =0A= In summary, it's mostly whether VCHR gets handled by the syscall or a=0A= wrapper?=0A= =0A= rick=0A= =0A= -Alan=0A= From owner-freebsd-hackers@freebsd.org Mon Sep 21 01:40:29 2020 Return-Path: Delivered-To: freebsd-hackers@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 AA8913E2303 for ; Mon, 21 Sep 2020 01:40:29 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvnFS4Lhfz4prX for ; Mon, 21 Sep 2020 01:40:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f181.google.com with SMTP id n2so15161828oij.1 for ; Sun, 20 Sep 2020 18:40:28 -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; bh=MGzIkGrs37QG3Plh6VbO7iq0QNXuClLuPQ4xhaa16BU=; b=f6Ml+Ih73RCGtA81pDAjNT8/Q5uXoqI7cQExuQTiuMd/rtl+vWTqGvGyIJ31WCimjQ pdGH/wYmvH5e99MdUv9F/ZiIDwabvxUGML0/abg00sKjTTe36RsSw6aK43LsMX242Yhl rUknj26Y/KGR97bQreQaKKqUEVK6eon8dXgKCOHeJD3DVwTJtTKjXAeN7Z3Nlm5TtaIp /4DYUdzRzSzR8nmTdGJY9HtrQT8n63sGjyfbhUucAguAP7J+gqtNi08+YYBRgcXuQKgi Nc59R7WPMxkx+HbAkUnN8p56NENAccvdkeIVfFR3RYPse3abhSgCBa2WyF1MUF6g7Yr5 fujg== X-Gm-Message-State: AOAM530BmTh2gYjRwChtLzUXtRgOZcpEECLp0MKLRcs6iDnRpznuik5Z eeROMjdwaQLzjMQdnW2FIu7At91hCzPn2reCK3g5tTTsstM= X-Google-Smtp-Source: ABdhPJxIDswNKHWgJvmDMYTP6ww6jXodvFarW9zel8JlsN4dOUiTp/ZOgJqxUMVit816qc+lbrwVGC4wdUf2JvOpPdY= X-Received: by 2002:a05:6808:555:: with SMTP id i21mr15566633oig.55.1600652427228; Sun, 20 Sep 2020 18:40:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sun, 20 Sep 2020 19:40:16 -0600 Message-ID: Subject: Re: RFC: copy_file_range(3) To: Rick Macklem Cc: FreeBSD Hackers X-Rspamd-Queue-Id: 4BvnFS4Lhfz4prX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.181 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.02 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.007]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.02)[-1.022]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.990]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.181:from]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.181:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 01:40:29 -0000 On Sun, Sep 20, 2020 at 5:14 PM Rick Macklem wrote: > Alan Somers wrote: > >On Sun, Sep 20, 2020 at 9:58 AM Rick Macklem > wrote: > >>Alan Somers wrote: > >>>copy_file_range(2) is nifty, but it has a few sharp edges: > >>>1) Certain file systems don't support it, necessitating a write/read > based > >>>fallback > >>>2) It doesn't handle sparse files as well as SEEK_HOLE/SEEK_DATA > >>>3) It's slightly tricky to both efficiently deal with holes and also > >>>promptly respond to signals > >>> > >>>These problems aren't terribly hard, but it seems to me like most > >>>applications that use copy_file_range would share the exact same > >>>solutions. In particular, I'm thinking about cp(1), dd(1), and > >>>install(8). Those three could benefit from sharing a userland wrapper > that > >>>handles the above problems. > >>> > >>>Should we add such a wrapper to libc? If so, what should it be called, > and > >>>should it be public or just private to /usr/src ? > >>There has been a discussion on src-committers which I suggested should > >>be taken to a public mailing list. > >> > >>The basic question is... > >>Whether or not the copy_file_range(2) syscall should be compatible with > >>the Linux one. > >>When I did the syscall, I tried to make it Linux-compatible, arguing that > >>Linux is now a de-facto standard. > >>The Linux syscall only works on regular files, which is why Alan's patch > for > >>cp required a "fallback to the old way" for VCHR files like /dev/null. > >> > >>He is considering a wrapper in libc to provide FreeBSD specific > semantics, > >>which I have no problem with, so long as the naming and man page make > >>it clear that it is not compatible with the Linux syscall. > >>(Personally, I'd prefer a wrapper in libc to making the actual syscall > non-Linux > >> compatible, but that is just mho.) > >> > >>Hopefully this helps clarify what Alan is asking, rick > >> > >>I don't think the two questions are equivalent. I think that > copy_file_range(2) >>ought to work on character devices. Separately, even > it does, I think a userland >>wrapper would still be useful. It would > still be able to handle sparse files more >>efficiently than the > kernel-based vn_generic_copy_file_range. > I saw this also stated in your #2 above, but wonder why you think a wrapper > would handle holes more efficiently. > vn_generic_copy_file_range() does look for holes via SEEK_DATA/SEEK_HOLE > just like a wrapper would and retains them as far as possible. It also > looks > for blocks of all zero bytes for file systems that do not support > SEEK_DATA/ > SEEK_HOLE (like NFS versions prior to 4.2) and creates holes for these in > the output file. > --> The only cases that I am aware of where the holes are not retained are: > - When the min holesize for the output file is larger than that of the > input file. > - When the hole straddles the byte range specified for the syscall. > (Or when the hole straddles two copy_file_range(2) syscalls, if you > prefer.) > > If you are copying the entire file and do not care how long the syscall > takes (which also implies how long it will take for a termination signal > like C to be handled), the most efficient usage is to specify > a "len" argument equal to UINT64_MAX. > --> This will usually copy the whole file in one gulp, although it is not > guaranteed to copy everything, given the Linux semantics definition > of it (an NFSv4.2 server can simply choose to copy less, for > example). > --> This allows the kernel to use whatever block size works > efficiently > and does not require an allocation of a large userspace > buffer for > the date, nor that the data be copied to/from userspace. > > The problem with doing the whole file in one gulp are: > - A large file can take quite a while and any signal won't be processed > until > the gulp is done. > --> If you wrote a program that allocated a 100Gbyte buffer and then > copied a file using read(2)/write(2) with a size of 100Gbytes in a > loop, > you'd end up with the same result. > - As kib@ noted, if the input file never reports EOF (as /dev/zero does), > then the "one gulp" wouldn't end until storage is exhausted on the > output file(s) device and C wouldn't stop it (since it is one > big > syscall). > --> As such, I suggested that, if the syscall is extended to allow > VCHR, > that the "len" argument be clipped at "K Mbytes" for that case > to > avoid filling the storage device before being able to C > out > of it, for this case. > I suppose the answer for #3 is... > - smaller "len" allows for quicker response to signals > but > - smaller "len" results in less efficient use of the syscall. > > Your patch for "cp" seemed fine, but used a small "len" and, as such, > made the use of copy_file_range(2) less efficient. > > All I see the wrapper dong is handling the VCHR case (if the syscall > remains > as it is now and returns EINVAL to be compatible with Linux) and making > some rather arbitrary choice w.r.t. how big "len" should be. > --> Choosing an appropriate "len" might better be left to the specific use > case, I think? > > In summary, it's mostly whether VCHR gets handled by the syscall or a > wrapper? > 1) In order to quickly respond to a signal, a program must use a modest len with copy_file_range 2) If a hole is larger than len, that will cause vn_generic_copy_file_range to truncate the output file to the middle of the hole. Then, in the next invocation, truncate it again to a larger size. 3) The result is a file that is not as sparse as the original. For example, on UFS: $ truncate -s 1g sparsefile $ cp sparsefile sparsefile2 $ du -sh sparsefile* 96K sparsefile 32M sparsefile2 My idea for a userland wrapper would solve this problem by using SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use copy_file_range for everything else with a modest len. Alternatively, we could eliminate the need for the wrapper by enabling copy_file_range for every file system, and making vn_generic_copy_file_range interruptible, so copy_file_range can be called with large len without penalizing signal handling performance. -Alan From owner-freebsd-hackers@freebsd.org Mon Sep 21 03:10:56 2020 Return-Path: Delivered-To: freebsd-hackers@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 328123E3F25 for ; Mon, 21 Sep 2020 03:10:56 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (midget.dons.net.au [IPv6:2403:5800:5101:0:ea:1cff:fefa:f00]) (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 "dons.net.au", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BvqFn4qZhz4tWl for ; Mon, 21 Sep 2020 03:10:52 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id 08L3AXkf052123 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 21 Sep 2020 12:40:33 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id 08L3A9hG049286 for ; Mon, 21 Sep 2020 12:40:09 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-be813b1f1da6d6b27d681222cb70cc4f5b642383: 2001:44b8:1d2:8900:4e5:b646:accf:7ddf Received: from [IPv6:2001:44b8:1d2:8900:4e5:b646:accf:7ddf] ([IPv6:2001:44b8:1d2:8900:4e5:b646:accf:7ddf] [2001:44b8:1d2:8900:4e5:b646:accf:7ddf]) by midget.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id 08L3A3MQ048928; Mon, 21 Sep 2020 12:40:09 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: ASPEED video driver From: "O'Connor, Daniel" In-Reply-To: <8b15ca21-07d1-7eb1-4d99-3654af585052@rlwinm.de> Date: Mon, 21 Sep 2020 12:40:03 +0930 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6E73BD01-C337-405F-8E05-BCFDBEE45FE2@dons.net.au> References: <8851FC7F-979D-4CDC-8513-CE893B2EF269@dons.net.au> <8b15ca21-07d1-7eb1-4d99-3654af585052@rlwinm.de> To: Crest X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Spam-Score: 0.1 () No, score=0.1 required=5.0 tests=HELO_MISC_IP, HELO_NO_DOMAIN, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4BvqFn4qZhz4tWl X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.56 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.020]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.03)[-1.027]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-1.01)[-1.009]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 03:10:56 -0000 > On 21 Sep 2020, at 07:16, Crest wrote: > I have no solution for the question you've asked, but I may have a = solution for your problem. Over the years I've found the different IPMI = KVM implementations terrible to use (slow to update, ridiculous input = lag, keyboard layout fuck ups, etc.). Instead I prefer to use the IPMI = Serial over LAN interface to install fresh systems avoiding the trouble = of emulating a keyboard (and mouse) and capturing the video output. On = most servers you can interrupt the boatloader via the serial connection = and enable dual console operation in FreeBSD. Some of the buggier IPMI = implementations work better with *only* a serial console enabled. >=20 > This example should work for most modern x64 server boards (with = minimal changes) >=20 > boot_multicons=3D"YES" # Enable multi console support > boot_serial=3D"YES" # Enable serial output > console=3D"comconsole,vidconsole" # On UEFI systems try efi instead > comconsole_speed=3D"115200" # Most boards default to 115200 baud = instead of the 9600 FreeBSD uses for legacy reasons > # comconsole_port=3D"0x2f8" # If the Serial over LAN is mapped to = COM2, check dmesg | grep uart >=20 > Sorry if this reads like a "you're holding it wrong" kind of answer, = but I haven't had much success with IPMI keyboard and video redirection = over the years. Thanks, unfortunately we do need a local X server for commissioning of = the system. I do have SOL setup because I find that sometimes the BIOS ignores = keypresses via the web console but the serial one works fine.. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Mon Sep 21 04:28:24 2020 Return-Path: Delivered-To: freebsd-hackers@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 8AB0A3E5398 for ; Mon, 21 Sep 2020 04:28:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0600.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::600]) (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 4BvrzC2yMRz3Swf; Mon, 21 Sep 2020 04:28:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jLUH1Fuq3cASsq0YNcRjCKt3D3WJ3YtndFe8Sq/Y9ReItIPWnOk1HAD71uYsQho9rpJsck7wTLXN9Turwsn5X04xq7OkLmEnHQxzDksrtcnPKGzFmbleZBb2jJCeLHEHtMn17zvKADtrQYFFI4esfsli0U2UTrCfY0u9jpDAxDa2JR9sdek4yE+XShyndrZnvmHZ01wcqINv4ZhYGu0ZAnAc3fh1ZPxy1HEsXHJX7QbAkPw2fvkk3OBI84T7PIX30b+/bHwPCl3spGVTlwwCxFFwztqvILURnjv2R/rIVIuU1Auem7w3+JV24LTc4rZfdt2qMdj5FYXKa/nHh3nDOw== 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=Rk/N3vf2nVuytPuqSizw0BpxN/PC5szQZsJKVbkXPBs=; b=ngHoIID9BuPYZWsQ1okfdLz2IGU9EAhnxl3S577qVm5l6cod9ApOe8x2Z/0X6bl6hewm7xMyrImWQbLZj51Mj6aojUEow+9awl8Pi7nZy4R2KrDwI/9MqTq4rN1C/saTLA2N9y/StB06zC0OXlPeypla04+dAF2ALp0N54bYbQ6sMJsY3ZhBUKn0Whzi4FND1bcInncF0yPtr98UpWyZFvYhmbw5k+ftFiLSy+vzSVG3ZkPhD7ldzC1Jpu1SMEnTpK7ArF09ia743pDoiaU3V1NV2pI/W/paxCcPqBRHoE4zuSHLN/anQg3nBg2VsX87oOBZUt7jUij5hGVYqrOqAg== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rk/N3vf2nVuytPuqSizw0BpxN/PC5szQZsJKVbkXPBs=; b=Ru1F2YA+LaZ4b2uFbBeOwTrrlWOlouxIgFXo3bSdOuzcLt5xTwsCnKLfJ4pI94gxhwkNZwsdtjRLQ4olOTvAJUvvrIZfytLHNUQ8K/oO5+6PEV8NMqB6RO7z1Be/4jBUFsXrQtbReNEFCqAlzrpkGeg5se8jgf+3R2eTruCGZpc+3CrfBM15QaTXMA3K5quwRuaUqYoVV+stLnC/tQru1ytKtNumkLYO5VD4rYyp+nv9cC0S27wWUdHptpbAnP8lP9wh+CcWWR+FMTFlSUrr134Ip7omcC46K+MWd1KQK9kc/048OhpW3VqWukl4k28MyKVoV7dZSuwKRDl4NJBJZg== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTBPR01MB3695.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:26::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Mon, 21 Sep 2020 04:28:21 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3391.024; Mon, 21 Sep 2020 04:28:21 +0000 From: Rick Macklem To: Alan Somers CC: FreeBSD Hackers Subject: Re: RFC: copy_file_range(3) Thread-Topic: RFC: copy_file_range(3) Thread-Index: AQHWj2Uep8NVOqCTP0KuS7h/nlgLPqlxrARqgAAEfICAAHAflYAAMOYAgAApba8= Date: Mon, 21 Sep 2020 04:28:21 +0000 Message-ID: References: , In-Reply-To: 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: d5a9822a-1c45-4d8c-98c6-08d85de6c5da x-ms-traffictypediagnostic: YTBPR01MB3695: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1247; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6VDMQ0jRbVrQHd+d82Sl8Bxs/zU8QzTGHBRaBcpe5nI4v8umosjhUJm42kqf9/kEysDqsiI4S7oOqT/01I4aOh5R04bJVY6f6gMozTB1qn6BpdQm5vaZTUak4jwuAiWbFfzRF6fTdQJXwGM9cu6ZvWgMAgtyuhZuBB7y9rE2HHG7RHZ14zB6O6uJOiKawXFedhd/YZcG2f7NeNqQfE2SjGqOm7y0p7REZSiRIC1YqMBJgbxPWXG78dOr8kP2uofit5JVI5teDFCjdMhmefkqWWMCe/7VZiRnVIpg4M8Dqd0j1ylWyn9SRVARMhGaeTXFNKsQmZyeUslBfL0bqtP0sg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(376002)(136003)(346002)(39850400004)(366004)(8676002)(71200400001)(186003)(6506007)(53546011)(6916009)(5660300002)(7696005)(316002)(786003)(450100002)(33656002)(478600001)(86362001)(66556008)(64756008)(66446008)(66476007)(66946007)(4326008)(76116006)(8936002)(91956017)(52536014)(2906002)(55016002)(9686003)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 1oJUb68fWf3GbGqTST+68q5dz13YRXWVPpdi7K6v2RCG7VmKu5MZZmdnYLeItUKJKRwofi2yRtq8XncyAWxv+cN3mpK49vy18WEMhr+duevLkWM0x6hRXIhR9Qw+mr3magLcfAq4ojIJxstSTu+387fNCHUpUrDHiRPZA6i84lM6rU2BqUTIhTuQaPPEQ+V6LcgsNQUSp+Bc0LGP0rKvrLuPa7Ki5wFlQrrS8M0EuncPtTIehJXrrfxRkCBqGnp4/QS+yl0FVJu6CONKWVyOMe8CWF4WzvAmzvhDIWh712KsULGAjdwIGwzm1H07dziuVLh0FTPktA+uR+b177yUAL3VYreYk1/xHUgoycP/FvIbC4a9QvLuvOEFVFqVoCDg4Np9bMru8KHs+YTiWqv5PLjKvOSVvG/fNAFaUZ91wqNKubrMUuqZhD0xgxwpIWBQN+7WJ+Mq0q7Ja9brjzHd6TV+9yrQcsCYpUgKootn024NAuwhW+vBXpc8ylCdm0fzlSUnezYTV/eN1zXWTe4OFHtN68LXT0z325UT+bxaAPLB5IA+i3gJmRxSweREfe+rLYkz8qNYKY4HDqbm91IlAcWAbaYjGLUZqze0nyU+EFlPSCb5oegU9MExsSXFPyfne+2Myfp0VII+fdZ8gMG5jQqBZUqS/da9oLRNqaqHOAkF5Phx4+BH4EzRWE2VTDqjwytiMKFZ4J6dFUfc46MiYA== x-ms-exchange-transport-forked: True 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d5a9822a-1c45-4d8c-98c6-08d85de6c5da X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2020 04:28:21.5834 (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: +vX0Wep7wQpZTcHmldrkS3QymvhxqoS/MbxQatXjCzuisEH75hpyRnM41aZ9czqgmL3nqCCTiU3q5DYvIMPPUQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3695 X-Rspamd-Queue-Id: 4BvrzC2yMRz3Swf X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=Ru1F2YA+; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5d::600 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.02)[-1.022]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-0.94)[-0.937]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 04:28:24 -0000 [I have only indented your most recent comments]=0A= Alan Somers wrote:=0A= On Sun, Sep 20, 2020 at 5:14 PM Rick Macklem > wrote:=0A= Alan Somers wrote:=0A= >On Sun, Sep 20, 2020 at 9:58 AM Rick Macklem >> wrote:=0A= >>Alan Somers wrote:=0A= >>>copy_file_range(2) is nifty, but it has a few sharp edges:=0A= >>>1) Certain file systems don't support it, necessitating a write/read bas= ed=0A= >>>fallback=0A= >>>2) It doesn't handle sparse files as well as SEEK_HOLE/SEEK_DATA=0A= >>>3) It's slightly tricky to both efficiently deal with holes and also=0A= >>>promptly respond to signals=0A= >>>=0A= >>>These problems aren't terribly hard, but it seems to me like most=0A= >>>applications that use copy_file_range would share the exact same=0A= >>>solutions. In particular, I'm thinking about cp(1), dd(1), and=0A= >>>install(8). Those three could benefit from sharing a userland wrapper t= hat=0A= >>>handles the above problems.=0A= >>>=0A= >>>Should we add such a wrapper to libc? If so, what should it be called, = and=0A= >>>should it be public or just private to /usr/src ?=0A= >>There has been a discussion on src-committers which I suggested should=0A= >>be taken to a public mailing list.=0A= >>=0A= >>The basic question is...=0A= >>Whether or not the copy_file_range(2) syscall should be compatible with= =0A= >>the Linux one.=0A= >>When I did the syscall, I tried to make it Linux-compatible, arguing that= =0A= >>Linux is now a de-facto standard.=0A= >>The Linux syscall only works on regular files, which is why Alan's patch = for=0A= >>cp required a "fallback to the old way" for VCHR files like /dev/null.=0A= >>=0A= >>He is considering a wrapper in libc to provide FreeBSD specific semantics= ,=0A= >>which I have no problem with, so long as the naming and man page make=0A= >>it clear that it is not compatible with the Linux syscall.=0A= >>(Personally, I'd prefer a wrapper in libc to making the actual syscall no= n-Linux=0A= >> compatible, but that is just mho.)=0A= >>=0A= >>Hopefully this helps clarify what Alan is asking, rick=0A= >>=0A= >>I don't think the two questions are equivalent. I think that copy_file_r= ange(2) >>ought to work on character devices. Separately, even it does, I = think a userland >>wrapper would still be useful. It would still be able t= o handle sparse files more >>efficiently than the kernel-based vn_generic_c= opy_file_range.=0A= I saw this also stated in your #2 above, but wonder why you think a wrapper= =0A= would handle holes more efficiently.=0A= vn_generic_copy_file_range() does look for holes via SEEK_DATA/SEEK_HOLE=0A= just like a wrapper would and retains them as far as possible. It also look= s=0A= for blocks of all zero bytes for file systems that do not support SEEK_DATA= /=0A= SEEK_HOLE (like NFS versions prior to 4.2) and creates holes for these in= =0A= the output file.=0A= --> The only cases that I am aware of where the holes are not retained are:= =0A= - When the min holesize for the output file is larger than that of the= =0A= input file.=0A= - When the hole straddles the byte range specified for the syscall.=0A= (Or when the hole straddles two copy_file_range(2) syscalls, if you= =0A= prefer.)=0A= =0A= If you are copying the entire file and do not care how long the syscall=0A= takes (which also implies how long it will take for a termination signal=0A= like C to be handled), the most efficient usage is to specify=0A= a "len" argument equal to UINT64_MAX.=0A= --> This will usually copy the whole file in one gulp, although it is not= =0A= guaranteed to copy everything, given the Linux semantics definition= =0A= of it (an NFSv4.2 server can simply choose to copy less, for example= ).=0A= --> This allows the kernel to use whatever block size works efficien= tly=0A= and does not require an allocation of a large userspace buffer= for=0A= the date, nor that the data be copied to/from userspace.=0A= =0A= The problem with doing the whole file in one gulp are:=0A= - A large file can take quite a while and any signal won't be processed unt= il=0A= the gulp is done.=0A= --> If you wrote a program that allocated a 100Gbyte buffer and then=0A= copied a file using read(2)/write(2) with a size of 100Gbytes in a = loop,=0A= you'd end up with the same result.=0A= - As kib@ noted, if the input file never reports EOF (as /dev/zero does),= =0A= then the "one gulp" wouldn't end until storage is exhausted on the=0A= output file(s) device and C wouldn't stop it (since it is one b= ig=0A= syscall).=0A= --> As such, I suggested that, if the syscall is extended to allow VCH= R,=0A= that the "len" argument be clipped at "K Mbytes" for that case t= o=0A= avoid filling the storage device before being able to C ou= t=0A= of it, for this case.=0A= I suppose the answer for #3 is...=0A= - smaller "len" allows for quicker response to signals=0A= but=0A= - smaller "len" results in less efficient use of the syscall.=0A= =0A= Your patch for "cp" seemed fine, but used a small "len" and, as such,=0A= made the use of copy_file_range(2) less efficient.=0A= =0A= All I see the wrapper dong is handling the VCHR case (if the syscall remain= s=0A= as it is now and returns EINVAL to be compatible with Linux) and making=0A= some rather arbitrary choice w.r.t. how big "len" should be.=0A= --> Choosing an appropriate "len" might better be left to the specific use= =0A= case, I think?=0A= =0A= In summary, it's mostly whether VCHR gets handled by the syscall or a=0A= wrapper?=0A= =0A= > 1) In order to quickly respond to a signal, a program must use a modest l= en with > copy_file_range=0A= Does this matter? Or put another way, is a 1-2sec delay in response to C=0A= an issue for "cp".=0A= When kib@ reviewed the syscall, he did not see the delay in signal handling= =0A= a significant problem, noting that it is no different than a large process = core=0A= dumping.=0A= =0A= > 2) If a hole is larger than len, that will cause vn_generic_copy_file_ran= ge to=0A= > truncate the output file to the middle of the hole. Then, in the next in= vocation, =0A= > truncate it again to a larger size.=0A= > 3) The result is a file that is not as sparse as the original.=0A= >=0A= > For example, on UFS:=0A= > $ truncate -s 1g sparsefile=0A= > $ cp sparsefile sparsefile2=0A= > $ du -sh sparsefile*=0A= > 96K sparsefile=0A= > 32M sparsefile2=0A= If you care about maintaining sparseness, a "len" of 100Mbytes or more woul= d=0A= be a reasonable choice. Since "cp" has never maintained sparseness, I didn'= t=0A= suggest such a size when I reviewed your patch for "cp".=0A= --> I/O subsystem performance varies widely, but I think 100Mbytes will lim= it=0A= the delay in signal handling to about 1sec. Isn't that quick enough?= =0A= =0A= > My idea for a userland wrapper would solve this problem by using =0A= > SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use copy_file_ra= nge for =0A= > everything else with a modest len. Alternatively, we could eliminate the= need for=0A= > the wrapper by enabling copy_file_range for every file system, and making= =0A= > vn_generic_copy_file_range interruptible, so copy_file_range can be calle= d with=0A= > large len without penalizing signal handling performance.=0A= The problem with doing this is it largely defeats the purpose of copy_file_= range().=0A= 1 - What about file systems that do not support SEEK_DATA/SEEK_HOLE.=0A= (All NFS mounts except NFSv4.2 ones against servers that support the= =0A= NFSv4.2 Seek operation are in this category.)=0A= 2 - For NFSv4.2 with servers that support Seek, the copy of an entire file= =0A= can be done via a few (or only one) RPC if you make "len" large and=0A= don't use Seek.=0A= If you combine using Seek with len =3D=3D2Mbytes, then you do a lot mo= re RPCs=0A= with associated overheads and RPC RTT delays. You still avoid moving a= ll=0A= the data across the wire, but you do lose a lot of the performance adv= antage.=0A= =0A= I could have made copy_file_range(2) a lot simpler if the generic code didn= 't=0A= try and maintain holes, but I wanted it to work well for file systems that = did=0A= not support SEEK_DATA/SEEK_HOLE.=0A= =0A= I'd suggest you try patching "cp" to use a 100Mbyte "len" for copy_file_ran= ge()=0A= and test that.=0A= You should fine the sparseness is mostly maintained and that you can = C=0A= out of a large file copy without undue delay.=0A= Then try it over NFS mounts (both v4.2 and v3) for the same large sparse fi= le.=0A= =0A= You can also code up a patched "cp" using SEEK_DATA/SEEK_HOLE and see=0A= how they compare.=0A= =0A= rick=0A= =0A= =0A= -Alan=0A= From owner-freebsd-hackers@freebsd.org Mon Sep 21 14:46:23 2020 Return-Path: Delivered-To: freebsd-hackers@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 E742B3F37C5 for ; Mon, 21 Sep 2020 14:46:23 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bw6hF75SVz4L91 for ; Mon, 21 Sep 2020 14:46:21 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 08LEkC7H019502 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 21 Sep 2020 16:46:13 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1600699573; bh=Y/seyEi+OEpMrn4TLIJHQfxFDKgIgTwxIqZ5fAt27UM=; h=Date:From:To:Subject:In-Reply-To:References; b=CFHdv2bXOM6kfLD5smNEIuyXjEfGvWZeTW+BripudXUykz6Vc/8WQ6xW1sTqx8dRa pKRTFMQt5TvFeqTrWCvH47PPTcLsYA8eax8dK8ZLA53SjQcHCbqNBQ5IXVto+cuHt7 WnWsSx+QZ6dbm/KO8LUZrJtmOh9KvJMv2e/ru5hY= Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.16.1/8.16.1/Submit) with ESMTP id 08LEkCi5019499 for ; Mon, 21 Sep 2020 16:46:12 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Mon, 21 Sep 2020 16:46:12 +0200 (CEST) From: Wojciech Puchar To: "O'Connor, Daniel via freebsd-hackers" Subject: Re: ASPEED video driver In-Reply-To: <6E73BD01-C337-405F-8E05-BCFDBEE45FE2@dons.net.au> Message-ID: References: <8851FC7F-979D-4CDC-8513-CE893B2EF269@dons.net.au> <8b15ca21-07d1-7eb1-4d99-3654af585052@rlwinm.de> <6E73BD01-C337-405F-8E05-BCFDBEE45FE2@dons.net.au> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4Bw6hF75SVz4L91 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=fail (headers rsa verify failed) header.d=puchar.net header.s=default header.b=CFHdv2bX; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-1.02 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.24)[0.243]; NEURAL_HAM_MEDIUM(-0.96)[-0.959]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[puchar.net]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.01)[-1.007]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[puchar.net:-]; R_DKIM_REJECT(1.00)[puchar.net:s=default]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 14:46:24 -0000 by the way - can you tell me how to use this serial console in these shitty java interface to management? Or other - simpler - way to use it. I too would prefer to have simulated serial console. Much prefer. From owner-freebsd-hackers@freebsd.org Tue Sep 22 03:53:19 2020 Return-Path: Delivered-To: freebsd-hackers@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 5D2683DBBE1 for ; Tue, 22 Sep 2020 03:53:19 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (midget.dons.net.au [IPv6:2403:5800:5101:0:ea:1cff:fefa:f00]) (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 "dons.net.au", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwS8G1Hytz4Sj5 for ; Tue, 22 Sep 2020 03:53:17 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id 08M3r6js008984 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2020 13:23:06 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id 08M3qtDm008966 for ; Tue, 22 Sep 2020 13:22:55 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-be813b1f1da6d6b27d681222cb70cc4f5b642383: 2001:44b8:1d2:8900:e4c7:daac:1045:76ef Received: from [IPv6:2001:44b8:1d2:8900:e4c7:daac:1045:76ef] ([IPv6:2001:44b8:1d2:8900:e4c7:daac:1045:76ef] [2001:44b8:1d2:8900:e4c7:daac:1045:76ef]) by midget.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id 08M3qnad008964; Tue, 22 Sep 2020 13:22:55 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: ASPEED video driver From: "O'Connor, Daniel" In-Reply-To: Date: Tue, 22 Sep 2020 13:22:49 +0930 Cc: "O'Connor, Daniel via freebsd-hackers" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8851FC7F-979D-4CDC-8513-CE893B2EF269@dons.net.au> <8b15ca21-07d1-7eb1-4d99-3654af585052@rlwinm.de> <6E73BD01-C337-405F-8E05-BCFDBEE45FE2@dons.net.au> To: Wojciech Puchar X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Spam-Score: 0.1 () No, score=0.1 required=5.0 tests=HELO_MISC_IP, HELO_NO_DOMAIN, T_SPF_PERMERROR autolearn=unavailable autolearn_force=no version=3.4.2 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4BwS8G1Hytz4Sj5 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.76 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.985]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.03)[-1.027]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-1.25)[-1.248]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 03:53:19 -0000 > On 22 Sep 2020, at 00:16, Wojciech Puchar wrote: >=20 > by the way - can you tell me how to use this serial console in these = shitty java interface to management? >=20 > Or other - simpler - way to use it. >=20 > I too would prefer to have simulated serial console. Much prefer. FYI for Supermicro X11 boards the latest BMC firmware doesn't require = Java, it works with HTML5. The BIOS settings for enabling serial redirection on the X11SSHF are..: - Advanced -> Serial Port 2 Attribute =3D> SOL - Advanced -> Serial Port Console Redirection -> SOL/COM2 Console = Redirection =3D> Enabled - Advanced -> Serial Port Console Redirection -> SOL/COM2 Console = Redirection -> Settings - COM2 Bits per second =3D> 115200 - COM2 Redirection After BIOS POST =3D> Always Enable Annoyingly you can't use both physical serial ports *and* SOL (unlike X9 = boards where SOL could be COM3) PS with the 'virtual media' you can mount a FreeBSD ISO and do an = install completely over the network. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Tue Sep 22 08:17:46 2020 Return-Path: Delivered-To: freebsd-hackers@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 BC8AA3E1638 for ; Tue, 22 Sep 2020 08:17:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 4BwZ1P65w4z4fvv for ; Tue, 22 Sep 2020 08:17:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (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 phk.freebsd.dk (Postfix) with ESMTPS id 7F7AB1AF1A5; Tue, 22 Sep 2020 08:17:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 08M8HgWG074233 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 22 Sep 2020 08:17:42 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 08M8HdiB074232; Tue, 22 Sep 2020 08:17:39 GMT (envelope-from phk) To: "O'Connor, Daniel" , "O'Connor, Daniel via freebsd-hackers" cc: Wojciech Puchar Subject: Re: ASPEED video driver In-reply-to: From: "Poul-Henning Kamp" References: <8851FC7F-979D-4CDC-8513-CE893B2EF269@dons.net.au> <8b15ca21-07d1-7eb1-4d99-3654af585052@rlwinm.de> <6E73BD01-C337-405F-8E05-BCFDBEE45FE2@dons.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74230.1600762659.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2020 08:17:39 +0000 Message-ID: <74231.1600762659@critter.freebsd.dk> X-Rspamd-Queue-Id: 4BwZ1P65w4z4fvv X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.99 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.04)[-1.035]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_MEDIUM(-1.01)[-1.012]; NEURAL_SPAM_SHORT(0.06)[0.057]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 08:17:46 -0000 -------- O'Connor, Daniel via freebsd-hackers writes: > FYI for Supermicro X11 boards the latest BMC firmware doesn't require Ja= va, it works with HTML5. > > The BIOS settings for enabling serial redirection on the X11SSHF are..: It would be great if people put such wisdom on our wiki... -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@freebsd.org Tue Sep 22 10:59:30 2020 Return-Path: Delivered-To: freebsd-hackers@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 5CE213E45FD for ; Tue, 22 Sep 2020 10:59:30 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (midget.dons.net.au [IPv6:2403:5800:5101:0:ea:1cff:fefa:f00]) (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 "dons.net.au", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bwdbz1tlTz3ZMZ for ; Tue, 22 Sep 2020 10:59:26 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id 08MAx7o3020442 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2020 20:29:07 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id 08MAwlCk020423 for ; Tue, 22 Sep 2020 20:28:47 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-be813b1f1da6d6b27d681222cb70cc4f5b642383: 2403:5800:5101:0:f0b6:d923:a0b4:a731 Received: from [IPv6:2403:5800:5101:0:f0b6:d923:a0b4:a731] ([IPv6:2403:5800:5101:0:f0b6:d923:a0b4:a731] [2403:5800:5101:0:f0b6:d923:a0b4:a731]) by midget.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id 08MAwguw020419; Tue, 22 Sep 2020 20:28:47 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: ASPEED video driver From: "O'Connor, Daniel" In-Reply-To: <74231.1600762659@critter.freebsd.dk> Date: Tue, 22 Sep 2020 20:28:42 +0930 Cc: "O'Connor, Daniel via freebsd-hackers" , Wojciech Puchar Content-Transfer-Encoding: quoted-printable Message-Id: <0AD6C099-59D9-4F84-8986-14080693696D@dons.net.au> References: <8851FC7F-979D-4CDC-8513-CE893B2EF269@dons.net.au> <8b15ca21-07d1-7eb1-4d99-3654af585052@rlwinm.de> <6E73BD01-C337-405F-8E05-BCFDBEE45FE2@dons.net.au> <74231.1600762659@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Spam-Score: -1 () No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4Bwdbz1tlTz3ZMZ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.41 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.04)[-1.038]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-0.88)[-0.876]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 10:59:30 -0000 > On 22 Sep 2020, at 17:47, Poul-Henning Kamp = wrote: >=20 > -------- > O'Connor, Daniel via freebsd-hackers writes: >=20 >> FYI for Supermicro X11 boards the latest BMC firmware doesn't require = Java, it works with HTML5. >>=20 >> The BIOS settings for enabling serial redirection on the X11SSHF = are..: >=20 > It would be great if people put such wisdom on our wiki... Here you go :) https://wiki.freebsd.org/SerialConsole -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Tue Sep 22 12:45:16 2020 Return-Path: Delivered-To: freebsd-hackers@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 70F863E8340 for ; Tue, 22 Sep 2020 12:45:16 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bwgy33jkLz3xTv for ; Tue, 22 Sep 2020 12:45:15 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [178.254.11.41] (helo=r314251-amd64) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKhfU-0001D5-RL for freebsd-hackers@freebsd.org; Tue, 22 Sep 2020 14:45:12 +0200 Date: Tue, 22 Sep 2020 14:45:10 +0200 From: Matthias Apitz To: freebsd-hackers@freebsd.org Subject: code review of C-code Message-ID: <20200922124510.GA36026@r314251-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 8.0-CURRENT (i386) User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 178.254.11.41 X-Rspamd-Queue-Id: 4Bwgy33jkLz3xTv X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of guru@unixarea.de has no SPF policy when checking 178.254.4.101) smtp.mailfrom=guru@unixarea.de X-Spamd-Result: default: False [4.49 / 15.00]; HAS_REPLYTO(0.00)[guru@unixarea.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[178.254.4.101:from]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; RCVD_IN_DNSWL_LOW(-0.10)[178.254.4.101:from]; ARC_NA(0.00)[]; SUBJECT_ENDS_SPACES(0.50)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.73)[0.729]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[unixarea.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.969]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.99)[0.991]; R_SPF_NA(0.00)[no SPF record]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 12:45:16 -0000 Hello, Do we have for FreeBSD (or someone from his work or other projects) a good guide for how to do code review in C (and also Perl and Java) sources. Thanks in advance matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin) From owner-freebsd-hackers@freebsd.org Wed Sep 23 01:18:21 2020 Return-Path: Delivered-To: freebsd-hackers@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 6204A3E7755 for ; Wed, 23 Sep 2020 01:18:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660084.outbound.protection.outlook.com [40.107.66.84]) (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 4Bx0g03yqhz41yS; Wed, 23 Sep 2020 01:18:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KYAGibQTi9/NifEMNU7tm7Nz9dE5OJc5nJoAqDMORufQ+QiI+0hfh58E0/Ao9UjExdQQJD4xLXOr6taRKQV65AGrcNQdHTSBAatFVqSSJbCDTX/AJIIRWl8qBnDEOyiz41eIELyoVHRsVIeDFRHwD8ik2B9q8D1p0Y5ZJpvSc6nb+mXX3zmp6R233ARZ6s/qbwJYWtKv+YN1tHVqpwmhy2JF2RVB7/FT9hEUgqPZhaqnH61caPxClt1gBO47jZAvryQraWHVORPVs1fzjsIN1qOrD3ZZIPieHj0bLXqvVT2ZZZiFRoS9rclMPyHzQFhaSu0EdXOeXcksmllA08DMaQ== 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=eiZ1Ji+HG9wgUD5ucCdZ8YNFTWoAy2bXzxICx4tybUo=; b=hGJd6Szr6F/kn7yEKVd6HrEFthFWb2OcetoB7BWP+m93Lg1TLVJ0Yw6icgmDOhmK7jx/FBN/9Mcdce1QwRC1oCIIdLsXASY9CN/VPxlQYZ+FoShw51HJXtkqcyQ0WnHyHZQMHGnEYAp1tWff0Je/X1p8ioztvOh5ouUUzVS1pXVQ6aMZsWKHredwBrQ2ZyAnyjQrAnQFbKulbWbsHPHNevkhGhQjSLIsPI/Qh61e92UXu+lVUatNEVAWY3iF36jst8px7QClA2RuZyCIZfstC9XvmNhWC2rMoRZvWK4uoZ5akd8Cmcwo4fALVY/wU9+71bRMg719vdSTjn22/wuKlA== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eiZ1Ji+HG9wgUD5ucCdZ8YNFTWoAy2bXzxICx4tybUo=; b=wYzha3amS+ueBbrSrhwA4IeoMHLTKzfZ7vFll0Cue13zPusK/37CDAJfTGNGx3LajHmSnCYA8S7ABvTqq7jAvXFupHva87TvQ0+fuDYlOUXs1EGHYR/y35ZR/xLyDi5BwQvj/1WpwhipEhUKXAxXqGSj67nSKJHS5zYwf27oAJFx7xhdnf9cFrWQqN00IujWidXpNY4UfuGqD4NhhRHu4alTbC8Zj6jVZfVwg5JpCwm0VLQr0GUopuqjlN+sw1lxPeDxJuCy5aKHCRthVisH6/e2OgGeGXaUXjaixO/hWINA+PZeOUAODa+SICpXuXKJ53sMNci1uSwkJReL0BsDrw== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTXPR0101MB0832.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:f::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14; Wed, 23 Sep 2020 01:18:18 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3391.027; Wed, 23 Sep 2020 01:18:18 +0000 From: Rick Macklem To: Alan Somers CC: FreeBSD Hackers , Konstantin Belousov Subject: Re: RFC: copy_file_range(3) Thread-Topic: RFC: copy_file_range(3) Thread-Index: AQHWj2Uep8NVOqCTP0KuS7h/nlgLPqlxrARqgAAEfICAAHAflYAAMOYAgAMOVBw= Date: Wed, 23 Sep 2020 01:18:18 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 941dd4ec-0874-4e7f-6774-08d85f5e8dd6 x-ms-traffictypediagnostic: YTXPR0101MB0832: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3968; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UAoCPl6untVkLNCzki6YSMleTACIqYt2FV68YcKcG04a4eouzrVS1hyq/TlmuFDKqE+Zv9d5sJ0/xAVTm58DD7y1kvIEHX43bLETmrtWosEYxqs+FMXrMZKK3+7AXE3T1lVLX/hVfVqGrvtE00RvPZ3julXyyNdDsa05DF29nNl1I3xDavyI3W7lBbJ+ZdUX8qE8hRjBGN8+h3o3Xp3LNQzxIXwV2+42cpvefHZzw+RmJymbESEk45DahYRIIBN3bVsB6t4WrLas4FIlzWKkoF3ik4jd4qJMRtoDkWXK7xA7dNkczLzVlOBjeo81H8Wo x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(396003)(39850400004)(136003)(366004)(8676002)(66946007)(55016002)(64756008)(316002)(33656002)(786003)(99936003)(478600001)(66446008)(66576008)(71200400001)(66476007)(6916009)(9686003)(54906003)(52536014)(66556008)(8936002)(91956017)(6506007)(450100002)(2906002)(186003)(76116006)(5660300002)(7696005)(4326008)(83380400001)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0O+ougP7w05s4efAmLQxnBp2r/a7X+QJxxf9STZLrT4fUGs37WmEXvOfS7KFTod5lELikfPiUIQGUJR0ZZxnGM/CzC9rv3zf+mt40p5+pAXmEdGyHB2MOrMiveK3X2ywBucoBXZUcmI1jpyHUJF4/OnGFP4atPnh3qxysaGDqs37rTi3exKxDYWVZpBBeoLRJHPfs+1Qks48GsJK9kzI28Kvdrlzm+PoG2jkbP5WXQsT7784RfuBborxCvSINFPZJeJjXlzhOWTj3SngP6lFAsRGS2l6R6zWO3I/YxFKfZRSru6FDQwgsXmUIIKFTSJ680zMHnyW8xxm3E22Orxw08+yzVTmILjLleU4MjjhSqoeYyF/5s1xyMgpBYT5adAMJnm+vzD1FgAPmNs4yHwn3ycRU7zi/znT8V+UNm6EN60qszVSHAaGmm6BiqrXCPbGwJqc6evHQjlS8M/Klruf0YwlqPDTReV2NXcUBc4jBHUfQi22CiRPrsqjYIbzUwN9F79S9Yf1WdLB23asYajg8CxP9XNqsoN6pUK3F9Qcw9VSd9XZMGCxiRV7EzfDWuMbrD+APNHcjgESHFiQ81wo14ixH1esJaF4YOMYHB3myvYSgyqW9QN8yGAD/J4CRcZq/Ur7VOe6uGG4XrBXrEnyndLTHoVzJwXM7Tt0F9wmmKdCEgazXOS1gFgU7OTzK+AGnwtFAfdCA3nn5yhPFRBMbg== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_003_YTBPR01MB3966BA18F43F7B6353171E67DD380YTBPR01MB3966CANP_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 941dd4ec-0874-4e7f-6774-08d85f5e8dd6 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2020 01:18:18.2669 (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: 58AMYx0CFhjEBz5hVuI3GnHpwbEkbOTHSwEXjuBYb6YTNEK0HzXOuDqHUbn/fQXh27dfrVUcoIFo/qSLHR7JxA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB0832 X-Rspamd-Queue-Id: 4Bx0g03yqhz41yS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=wYzha3am; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.84 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.63 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-0.74)[-0.739]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-0.96)[-0.964]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.028]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.84:from]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 01:18:21 -0000 --_003_YTBPR01MB3966BA18F43F7B6353171E67DD380YTBPR01MB3966CANP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alan Somers wrote:=0A= [lots of stuff snipped]=0A= >1) In order to quickly respond to a signal, a program must use a modest le= n with >copy_file_range=0A= For the programs you have mentioned, I think the only signal handling would= =0A= be termination (C or SIGTERM if you prefer).=0A= I'm not sure what is a reasonable response time for this.=0A= I'd like to hear comments from others?=0A= - 1sec, less than 1sec, a few seconds, ...=0A= =0A= > 2) If a hole is larger than len, that will cause vn_generic_copy_file_ran= ge to=0A= > truncate the output file to the middle of the hole. Then, in the next in= vocation, =0A= > truncate it again to a larger size.=0A= > 3) The result is a file that is not as sparse as the original.=0A= Yes. So, the trick is to use the largest "len" you can live with, given how= long you=0A= are willing to wait for signal processing.=0A= =0A= > For example, on UFS:=0A= > $ truncate -s 1g sparsefile=0A= Not a very interesting sparse file. I wrote a little program to create one.= =0A= > $ cp sparsefile sparsefile2=0A= > $ du -sh sparsefile*=0A= > 96K sparsefile=0A= > 32M sparsefile2=0A= >=0A= > My idea for a userland wrapper would solve this problem by using =0A= > SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use copy_file_ra= nge for=0A= > everything else with a modest len. Alternatively, we could eliminate the= need for=0A= > the wrapper by enabling copy_file_range for every file system, and making= =0A= > vn_generic_copy_file_range interruptible, so copy_file_range can be calle= d with =0A= > large len without penalizing signal handling performance.=0A= =0A= Well, I ran some quick benchmarks using the attached programs, plus "cp" bo= th=0A= before and with your copy_file_range() patch.=0A= copya - Does what I think your plan is above, with a limit of 2Mbytes for "= len".=0A= copyb -Just uses copy_file_range() with 128Mbytes for "len".=0A= =0A= I first created the sparse file with createsparse.c. It is admittedly a wor= st case,=0A= creating alternating holes and data blocks of the minimum size supported by= =0A= the file system. (I ran it on a UFS file system created with defaults, so t= he minimum=0A= hole size is 32Kbytes.)=0A= The file is 1Gbyte in size with an Allocation size of 524576 ("ls -ls").=0A= =0A= I then ran copya, copyb, old-cp and new-cp. For NFS, I redid the mount befo= re=0A= each copy to avoid data caching in the client.=0A= Here's what I got:=0A= Elapsed time #RPCs Allocat= ion size ("ls -ls" on server)=0A= NFSv4.2 =0A= copya 39.7sec 16384copy+32768seek 524576=0A= copyb 10.2sec 104copy 524= 576=0A= old-cp 21.9sec 16384read+16384write 1048864=0A= new-cp 10.5sec 1024copy 5245= 76=0A= =0A= NFSv4.1=0A= copya 21.8sec 16384read+16384write 1048864=0A= copyb 21.0sec 16384read+16384write 1048864=0A= old-cp 21.8sec 16384read+16384write 1048864=0A= new-cp 21.4sec 16384read+16384write 1048864=0A= =0A= Local on the UFS file system=0A= copya 9.2sec n/a = 524576=0A= copyb 8.0sec n/a = 524576=0A= old-cp 15.9sec n/a = 1048864=0A= new-cp 7.9sec n/a = 524576=0A= =0A= So, for a NFSv4.2 mount, using SEEK_DATA/SEEK_HOLE is definitely=0A= a performance hit, due to all the RPC rtts.=0A= Your patched "cp" does fine, although a larger "len" reduces the=0A= RPC count against the server.=0A= All variants using copy_file_range() retain the holes.=0A= =0A= For NFSv4.1, it (not surprisingly) doesn't matter, since only NFSv4.2=0A= supports SEEK_DATA/SEEK_HOLE and VOP_COPY_FILE_RANGE().=0A= =0A= For UFS, everything using copy_file_range() works pretty well and=0A= retains the holes.=0A= Although "copya" is guaranteed to retain the holes, it does run noticably= =0A= slower than the others. Not sure why? Does the extra SEEK_DATA/SEEK_HOLE=0A= syscalls cost that much?=0A= =0A= The limitation of not using SEEK_DATA/SEEK_HOLE is that you will not=0A= retain holes that straddle the byte range copied by two subsequent=0A= copy_file_range(2) calls.=0A= --> This can be minimized by using a large "len", but that large "len"=0A= results in slower response to signal handling.=0A= =0A= I've attached the little programs, so you can play with them.=0A= (Maybe try different sparse schemes/sizes? It might be fun to=0A= make the holes/blocks some random multiple of hole size up=0A= to a limit?)=0A= =0A= rick=0A= ps: In case he isn't reading hackers these days, I've added kib@=0A= as a cc. He might know why UFS is 15% slower when SEEK_HOLE=0A= SEEK_DATA is used.=0A= =0A= =0A= -Alan=0A= --_003_YTBPR01MB3966BA18F43F7B6353171E67DD380YTBPR01MB3966CANP_ Content-Type: text/plain; name="copyb.c" Content-Description: copyb.c Content-Disposition: attachment; filename="copyb.c"; size=765; creation-date="Wed, 23 Sep 2020 01:14:16 GMT"; modification-date="Wed, 23 Sep 2020 01:14:16 GMT" Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN0cmluZy5o PgojaW5jbHVkZSA8ZmNudGwuaD4KI2luY2x1ZGUgPGVycm5vLmg+CiNpbmNsdWRlIDxzeXMvcGFy YW0uaD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3N0YXQuaD4KI2luY2x1 ZGUgPGVyci5oPgojaW5jbHVkZSA8dW5pc3RkLmg+CgppbnQKbWFpbihpbnQgYXJnYywgY2hhciAq YXJndltdKQp7CglpbnQgaSwgaW5mZCwgb3V0ZmQ7CglzdHJ1Y3Qgc3RhdCBpbnN0LCBvdXRzdDsK CW9mZl90IHNlZWtkYXRhLCBzZWVraG9sZSwgeGZlciwgb2ZmcG9zOwoJc2l6ZV90IGxlbjsKCXNz aXplX3QgcnNpejsKCWNoYXIgY3A7CgoJaWYgKGFyZ2MgIT0gMykKCQllcnJ4KDEsICJVc2FnZTog Y29weWIgPGluZmlsZT4gPG91dGZpbGU+Iik7CglpbmZkID0gb3Blbihhcmd2WzFdLCBPX1JET05M WSwgMCk7CglpZiAoaW5mZCA8IDApCgkJZXJyKDEsICJjYW4ndCBvcGVuICVzIiwgYXJndlsxXSk7 CglvdXRmZCA9IG9wZW4oYXJndlsyXSwgT19DUkVBVCB8IE9fUkRXUiwgMDY0NCk7CglpZiAob3V0 ZmQgPCAwKQoJCWVycigxLCAiY2FuJ3QgY3JlYXRlICVzIiwgYXJndlsyXSk7CgoJLyogTm93LCBj b3B5IGluZmQgdG8gb3V0ZmQuICovCglkbyB7CgkJc2Vla2RhdGEgPSBjb3B5X2ZpbGVfcmFuZ2Uo aW5mZCwgTlVMTCwgb3V0ZmQsIE5VTEwsCgkJICAgIDEyOCAqIDEwMjQgKiAxMDI0LCAwKTsKCX0g d2hpbGUgKHNlZWtkYXRhID4gMCk7Cn0K --_003_YTBPR01MB3966BA18F43F7B6353171E67DD380YTBPR01MB3966CANP_ Content-Type: text/plain; name="createsparse.c" Content-Description: createsparse.c Content-Disposition: attachment; filename="createsparse.c"; size=1139; creation-date="Wed, 23 Sep 2020 01:14:32 GMT"; modification-date="Wed, 23 Sep 2020 01:14:32 GMT" Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN0cmluZy5o PgojaW5jbHVkZSA8ZmNudGwuaD4KI2luY2x1ZGUgPGVycm5vLmg+CiNpbmNsdWRlIDxzeXMvcGFy YW0uaD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3N0YXQuaD4KI2luY2x1 ZGUgPGVyci5oPgojaW5jbHVkZSA8dW5pc3RkLmg+CgpzdGF0aWMgY2hhciBvdXRidWZbMTAyNCAq IDEwMjRdOwoKaW50Cm1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkKewoJaW50IGksIG91dGZk OwoJc3RydWN0IHN0YXQgaW5zdCwgb3V0c3Q7CglvZmZfdCBzZWVrZGF0YSwgc2Vla2hvbGUsIHhm ZXIsIG9mZnBvczsKCXNpemVfdCBsZW47Cglzc2l6ZV90IHJzaXo7CgljaGFyIGNwOwoJbG9uZyBo b2xlc2l6OwoKCWlmIChhcmdjICE9IDIpCgkJZXJyeCgxLCAiVXNhZ2U6IGNyZWF0ZXNwYXJzZSA8 aW5maWxlPiIpOwoJLyogRmlsbCBpbiBpbmJ1ZiB3aXRoIHRoZSBhbHBoYWJldCBvdmVyIGFuZCBv dmVyIGFuZCBvdmVyIGFnYWluLiAqLwoJY3AgPSAnYSc7Cglmb3IgKGkgPSAwOyBpIDwgc2l6ZW9m KG91dGJ1Zik7IGkrKykgewoJCW91dGJ1ZltpXSA9IGNwKys7CgkJaWYgKGNwID4gJ3onKQoJCQlj cCA9ICdhJzsKCX0KCW91dGZkID0gb3Blbihhcmd2WzFdLCBPX0NSRUFUIHwgT19SRFdSLCAwNjQ0 KTsKCWlmIChvdXRmZCA8IDApCgkJZXJyKDEsICJjYW4ndCBvcGVuICVzIiwgYXJndlsxXSk7CgoJ aG9sZXNpeiA9IGZwYXRoY29uZihvdXRmZCwgX1BDX01JTl9IT0xFX1NJWkUpOwoJaWYgKGhvbGVz aXogPD0gMCkKCQllcnIoMSwgIkNhbid0IGdldCBtaW4gaG9sZSBzaXplIik7CgkvKiBDcmVhdGUg dGhlIHNwYXJzZSBmaWxlLiAqLwoJeGZlciA9IDEwMjQgKiAxMDI0ICogMTAyNDsKcHJpbnRmKCJ4 ZmVyPSVqZFxuIiwgKGludG1heF90KXhmZXIpOwoJZm9yIChvZmZwb3MgPSAwOyBvZmZwb3MgPCB4 ZmVyOyBvZmZwb3MgKz0gMiAqIGhvbGVzaXopIHsKcHJpbnRmKCJ4ZmVyPSVqZCBvZmZwb3M9JWpk XG4iLCAoaW50bWF4X3QpeGZlciwgKGludG1heF90KW9mZnBvcyk7CgkJbHNlZWsob3V0ZmQsIGhv bGVzaXosIFNFRUtfQ1VSKTsKCQl3cml0ZShvdXRmZCwgb3V0YnVmLCBob2xlc2l6KTsKCX0KfQo= --_003_YTBPR01MB3966BA18F43F7B6353171E67DD380YTBPR01MB3966CANP_-- From owner-freebsd-hackers@freebsd.org Wed Sep 23 01:24:26 2020 Return-Path: Delivered-To: freebsd-hackers@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 71EE53E80AB for ; Wed, 23 Sep 2020 01:24:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660047.outbound.protection.outlook.com [40.107.66.47]) (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 4Bx0p14Dy3z42P4; Wed, 23 Sep 2020 01:24:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hv7+WwKFKH0A1buXKmHIgim/h0Nv8pxf4Vr8qUrud1YbXLY+rNiCOj5AV69Mp7CJm+ysFkdAqw/a/ZRTJdJUqrPNjqK3IBpLNXMMYGGjiLG0e93rmZBKecTg2M6dh/A9MWJfzeneRtZm788aVi+x7K2k/sJ219ZHCWTu+m5DMdb0+G6fvN/jZmbxSA3+aeHh61YIulKxZsd+S74jivA5qWvVFewSLMyjgtL9Y4L1P2jYm3TTHLe/7z6aK7WOLx2v1egfYypHgcb4YM+X4ohD/4nrpLp+PBIfJrTamq/C/u2/yDYVFRQqnKWpJUpVkGEuT8VTGmO8g/Yy3n8hYoy60A== 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=5Rybob+cDlQU3rJBtI9Gm5jsQEoI7P40wQ6BjvkeT6E=; b=UigLobXu2YcBiw2+2UAVyIb7RY7hOpLcY7O9rRX8nZRLsgiKzwPXdhrWyh9tWroITI7kIBOesJmflWpzYP9H1jJg/dRG5tH9RgrUgB8hZqk8fNZyhYlEdw8WISs5iDLQq2zs3U5C6o4KYS9KTDkMlFhjk8oU19YkXlkwgie5qNixvF+4bLfb2pqwcTyZV2YozFhPQZo1qOuAHKsVCgKvlKmWJ62A32D1nakj/97II0eXllYuVYG1hSIh4q4P5S+0VNcNks6vxWLGKl6WhA/9tJHlC8+2nAm3+PhVzCZVnYUZADGTA8AeidJ0oGEwUxex8tmqf2r8UzEZR7jwEud1Sw== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Rybob+cDlQU3rJBtI9Gm5jsQEoI7P40wQ6BjvkeT6E=; b=kkjOM+8Ha2jhlq2ELSvd1ai4lH9EQFCmCiSa85L8xeTFunyHIUDGm2e1UFQV5v3hgkk0J1YHFLIc6sH9H60U+zWyOPCjS3/9Vb1Edcb5UDji0f5OHZs68s2qM4HaLlw0IhQFfqdaS0mMLjuYV9hlgxnSpC7DtrM8zGxKrPNyYvtE89FtBl32G/XuHdWxXhsJJ1BaLB7tEjUoWH/by7qAxgQeRirAOiC3KpGNSKep9Yv/mE9EE6txabgeZ7E1NJ6oiTkXw7JKKYdlGbwQV6ln3ONHAoLLoCTXfjYOOi2PnnJHcr5OTLzO6oV9QnndeXMf95Uw0zrH325bOx8EgxqtHw== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTBPR01MB3439.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:16::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14; Wed, 23 Sep 2020 01:24:24 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3391.027; Wed, 23 Sep 2020 01:24:24 +0000 From: Rick Macklem To: Alan Somers CC: FreeBSD Hackers , Konstantin Belousov Subject: Re: RFC: copy_file_range(3) Thread-Topic: RFC: copy_file_range(3) Thread-Index: AQHWj2Uep8NVOqCTP0KuS7h/nlgLPqlxrARqgAAEfICAAHAflYAAMOYAgAMOVByAABEBfw== Date: Wed, 23 Sep 2020 01:24:24 +0000 Message-ID: References: , , In-Reply-To: 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: fbf80873-912f-444a-00dd-08d85f5f67dd x-ms-traffictypediagnostic: YTBPR01MB3439: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uavKB0fk01/v+oCnXiIpcE/n4741BdaqlumcMWnoEX4KdHT6PXj8ac8eUMBFivge8ru5Gompfvr419q1Eyg2qpPlPQmOpkgpE8Sqs7WEyVe2vLR3BLI7rPhnF/C6f9HLCari/ABYYBf5zXGEm/jYpb5Yqt9bKACwq0f4pTR8sHuNGvoPHFZRp2jrn7ulLT9LMDs4mtWNsJ2srcByd3Eqll0AptkA0NNVakdZg/ir/ef3l3eWeFqLSJLGIoZoSAY/8iq3Q69UM6Zk5V4o7k1etLTjW9dFcc9G8D53sITk+Y0KwLUAU0KrbXYxb8eeKDF0XR9EH24HBzuH+kiYCci+zmVcE31qZeWoCAMVC8lhsJDm9K+g9R3Ep7R4r2B06i9i x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(366004)(39830400003)(396003)(376002)(346002)(8936002)(71200400001)(52536014)(9686003)(91956017)(64756008)(66446008)(2940100002)(55016002)(83380400001)(66476007)(2906002)(53546011)(478600001)(86362001)(8676002)(66556008)(66946007)(6506007)(76116006)(5660300002)(6916009)(33656002)(786003)(54906003)(450100002)(7696005)(186003)(316002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qqFOnQTxA/KgTNnBrA9LWGP4qrAZc4cTzHCNpznNXCXuuRsvUtYQZIDYYPUO3RUDLD/AUHtn/LcKXvMDcSWvyJsVNCYisxiELjgELFX5JjTbzqCG6nX9I0nuwgJQuSesBh3R1ulMfNd6+Uw+7V0WkyNpcA04YWaCai9x7eB6RyVFzuh7NcLyuk1OSPiGNU+oqLVK8QGT4fvH25GXN04YcITNOTPJOrSihTbjkxOARVD7uTp0duuK2kgYF2zGVzegDO7ruw1mLLxkbGQmRLKdPEyS8GoP6VKuC+NdFTM36I58XcrUgMrxgQjW4PnDB5CPvTnuuKQKCa0+BOMzdc9U3vsQBdIy7DJ5JAR74ckTXZ4TF/oSybw26/xd2LataW9sGSwm3iUKIvcVZMlvg4zf2Wu34CQ0+pOqFfrXxgho0Myjlm3mTJv06NCiE6g+FqcHtu7W5Sn0Atk/Jf42EBBh1e3myjD+l/5aoVJJaRWEDL/Sv0RZomGyMt18If4jLYPP6aRRRUb98YNQjN7NWFlDfMJRIUUZmqDZe9b+ILWD1jW0Ost59jSiRCTi3RDZhh+xbYnxDN5vxwBsLcsUtojfes4LFXi4rBt9JdqoQhWXEQHaV4iyPGNk9Y7mGsZFTO/wGTtOM208ILjUsubdRR0zlPT+QMkHyi3dVloXjMivkSgxBaov4D5ysA44Sh9BpN4mG/uoNxdiUQOwILN+TChWtg== x-ms-exchange-transport-forked: True 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: fbf80873-912f-444a-00dd-08d85f5f67dd X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2020 01:24:24.1274 (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: 2QMqm1do+LNTA2RAJMvzHkbGIAiy0SSOTlxR8+0Z95jcL8KR8kA9uS/Y8rDKVNXCtaXOL79MNvEZ6kUgkJ9spQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3439 X-Rspamd-Queue-Id: 4Bx0p14Dy3z42P4 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=kkjOM+8H; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.47 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.94 / 15.00]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-0.997]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.47:from]; NEURAL_HAM_SHORT(-0.96)[-0.965]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.47:from] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 01:24:26 -0000 Oh, and I set=0A= vfs.nfs.maxcopyrange=3D134217728=0A= on the server.=0A= =0A= The current default is only 10Mbytes, but I think 128Mbytes=0A= is a more reasonable setting.=0A= =0A= rick=0A= ps: The server and client are only somewhat old Dell Latitude 6420=0A= laptops, so the tests were not done on server grade hardware.=0A= =0A= =0A= ________________________________________=0A= From: owner-freebsd-hackers@freebsd.org = on behalf of Rick Macklem =0A= Sent: Tuesday, September 22, 2020 9:18 PM=0A= To: Alan Somers=0A= Cc: FreeBSD Hackers; Konstantin Belousov=0A= Subject: Re: RFC: copy_file_range(3)=0A= =0A= Alan Somers wrote:=0A= [lots of stuff snipped]=0A= >1) In order to quickly respond to a signal, a program must use a modest le= n with >copy_file_range=0A= For the programs you have mentioned, I think the only signal handling would= =0A= be termination (C or SIGTERM if you prefer).=0A= I'm not sure what is a reasonable response time for this.=0A= I'd like to hear comments from others?=0A= - 1sec, less than 1sec, a few seconds, ...=0A= =0A= > 2) If a hole is larger than len, that will cause vn_generic_copy_file_ran= ge to=0A= > truncate the output file to the middle of the hole. Then, in the next in= vocation,=0A= > truncate it again to a larger size.=0A= > 3) The result is a file that is not as sparse as the original.=0A= Yes. So, the trick is to use the largest "len" you can live with, given how= long you=0A= are willing to wait for signal processing.=0A= =0A= > For example, on UFS:=0A= > $ truncate -s 1g sparsefile=0A= Not a very interesting sparse file. I wrote a little program to create one.= =0A= > $ cp sparsefile sparsefile2=0A= > $ du -sh sparsefile*=0A= > 96K sparsefile=0A= > 32M sparsefile2=0A= >=0A= > My idea for a userland wrapper would solve this problem by using=0A= > SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use copy_file_ra= nge for=0A= > everything else with a modest len. Alternatively, we could eliminate the= need for=0A= > the wrapper by enabling copy_file_range for every file system, and making= =0A= > vn_generic_copy_file_range interruptible, so copy_file_range can be calle= d with=0A= > large len without penalizing signal handling performance.=0A= =0A= Well, I ran some quick benchmarks using the attached programs, plus "cp" bo= th=0A= before and with your copy_file_range() patch.=0A= copya - Does what I think your plan is above, with a limit of 2Mbytes for "= len".=0A= copyb -Just uses copy_file_range() with 128Mbytes for "len".=0A= =0A= I first created the sparse file with createsparse.c. It is admittedly a wor= st case,=0A= creating alternating holes and data blocks of the minimum size supported by= =0A= the file system. (I ran it on a UFS file system created with defaults, so t= he minimum=0A= hole size is 32Kbytes.)=0A= The file is 1Gbyte in size with an Allocation size of 524576 ("ls -ls").=0A= =0A= I then ran copya, copyb, old-cp and new-cp. For NFS, I redid the mount befo= re=0A= each copy to avoid data caching in the client.=0A= Here's what I got:=0A= Elapsed time #RPCs Allocat= ion size ("ls -ls" on server)=0A= NFSv4.2=0A= copya 39.7sec 16384copy+32768seek 524576=0A= copyb 10.2sec 104copy 524= 576=0A= old-cp 21.9sec 16384read+16384write 1048864=0A= new-cp 10.5sec 1024copy 5245= 76=0A= =0A= NFSv4.1=0A= copya 21.8sec 16384read+16384write 1048864=0A= copyb 21.0sec 16384read+16384write 1048864=0A= old-cp 21.8sec 16384read+16384write 1048864=0A= new-cp 21.4sec 16384read+16384write 1048864=0A= =0A= Local on the UFS file system=0A= copya 9.2sec n/a = 524576=0A= copyb 8.0sec n/a = 524576=0A= old-cp 15.9sec n/a = 1048864=0A= new-cp 7.9sec n/a = 524576=0A= =0A= So, for a NFSv4.2 mount, using SEEK_DATA/SEEK_HOLE is definitely=0A= a performance hit, due to all the RPC rtts.=0A= Your patched "cp" does fine, although a larger "len" reduces the=0A= RPC count against the server.=0A= All variants using copy_file_range() retain the holes.=0A= =0A= For NFSv4.1, it (not surprisingly) doesn't matter, since only NFSv4.2=0A= supports SEEK_DATA/SEEK_HOLE and VOP_COPY_FILE_RANGE().=0A= =0A= For UFS, everything using copy_file_range() works pretty well and=0A= retains the holes.=0A= Although "copya" is guaranteed to retain the holes, it does run noticably= =0A= slower than the others. Not sure why? Does the extra SEEK_DATA/SEEK_HOLE=0A= syscalls cost that much?=0A= =0A= The limitation of not using SEEK_DATA/SEEK_HOLE is that you will not=0A= retain holes that straddle the byte range copied by two subsequent=0A= copy_file_range(2) calls.=0A= --> This can be minimized by using a large "len", but that large "len"=0A= results in slower response to signal handling.=0A= =0A= I've attached the little programs, so you can play with them.=0A= (Maybe try different sparse schemes/sizes? It might be fun to=0A= make the holes/blocks some random multiple of hole size up=0A= to a limit?)=0A= =0A= rick=0A= ps: In case he isn't reading hackers these days, I've added kib@=0A= as a cc. He might know why UFS is 15% slower when SEEK_HOLE=0A= SEEK_DATA is used.=0A= =0A= =0A= -Alan=0A= From owner-freebsd-hackers@freebsd.org Wed Sep 23 01:46:32 2020 Return-Path: Delivered-To: freebsd-hackers@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 636123E8AB4 for ; Wed, 23 Sep 2020 01:46:32 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4Bx1HV5CcWz43hK for ; Wed, 23 Sep 2020 01:46:30 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 1597940605C; Tue, 22 Sep 2020 18:46:19 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Rick Macklem cc: FreeBSD Hackers , hmurray@megapathdsl.net From: Hal Murray Subject: Re: RFC: copy_file_range(3) In-Reply-To: Message from Rick Macklem of "Wed, 23 Sep 2020 01:18:18 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Sep 2020 18:46:19 -0700 Message-Id: <20200923014619.1597940605C@ip-64-139-1-69.sjc.megapath.net> X-Rspamd-Queue-Id: 4Bx1HV5CcWz43hK X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of hmurray@megapathdsl.net has no SPF policy when checking 64.139.1.69) smtp.mailfrom=hmurray@megapathdsl.net X-Spamd-Result: default: False [1.64 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.03)[-0.030]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[megapathdsl.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.11)[0.112]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.06)[0.062]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4565, ipnet:64.139.0.0/18, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 01:46:32 -0000 > I'm not sure what is a reasonable response time for this. > I'd like to hear comments from others? > - 1sec, less than 1sec, a few seconds, ... My 2 cents. 1 second is the knee of the curve. It's noticeable but not really annoying. Over a second gets annoying. Under a second I probably won't notice. -- These are my opinions. I hate spam. From owner-freebsd-hackers@freebsd.org Wed Sep 23 10:24:31 2020 Return-Path: Delivered-To: freebsd-hackers@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 9071C3F4E35 for ; Wed, 23 Sep 2020 10:24:31 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (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 4BxDn96nH7z4ZVZ for ; Wed, 23 Sep 2020 10:24:29 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165e4a.dip0.t-ipconnect.de [91.22.94.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 645C027C84 for ; Wed, 23 Sep 2020 12:24:06 +0200 (CEST) Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 8F70F7385 for ; Wed, 23 Sep 2020 12:24:01 +0200 (CEST) Date: Wed, 23 Sep 2020 12:24:01 +0200 Message-ID: <20200923122401.Horde.uXmEqpCzVbCyXTuyukZeRwU@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-hackers@freebsd.org Subject: Re: RFC: copy_file_range(3) References: In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_T-00OrdGI7S8EnwxWySsbl8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 4BxDn96nH7z4ZVZ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.01)[-1.010]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.03)[-1.031]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.16)[0.162]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.94.74:received] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 10:24:31 -0000 This message is in MIME format and has been PGP signed. --=_T-00OrdGI7S8EnwxWySsbl8 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Rick Macklem (from Wed, 23 Sep 2020=20=20 01:18:18=20+0000): > Well, I ran some quick benchmarks using the attached programs, plus "cp" = both > before and with your copy_file_range() patch. > copya - Does what I think your plan is above, with a limit of=20=20 >=202Mbytes for "len". > copyb -Just uses copy_file_range() with 128Mbytes for "len". > > I first created the sparse file with createsparse.c. It is=20=20 >=20admittedly a worst case, > creating alternating holes and data blocks of the minimum size supported = by > the file system. (I ran it on a UFS file system created with=20=20 >=20defaults, so the minimum > hole size is 32Kbytes.) Not related to the topic of changing cp, but related to the topic of=20=20 copy_file_range:=20does nullfs support (as in pass-through to the=20=20 underlying=20FS) copy_file_range? Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_T-00OrdGI7S8EnwxWySsbl8 Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJfayJBAAoJEBINsJsD+NiGgo8P/A/Ung4yq0mE/BqBAfeTLlT+ HYu096g1fS31A65swMLFJ4QrrJi/TDUWCGd+YLulcDrtoHoS2TSDZBKGH9XJTl+W JSRq6/f5Mm+swA1276AbHz7SKiUsZh942bTGeDmPPUYtRKKhbMjUTTMY72jH7xJn hUUlakNlChUn6CD9qFv0FMO7Y1SxOUNDhs/bXXuyxisyuVDHpVAsOHCIXAPBvmlt V0suqNeEu8svWRrKiAbCgElcwBWRuWXgHdx0iZmsCHopVD09BXCwIadP/QXtUCvP Q+rUZQPuFjBhCtm2Zic+xlK9I/pvhFpXEYK1zIoDnNohKmqULlkRJr7gyZi/ELJ0 4umFy2+VeeHI3SBspsi/LhnQKrqvfUuYznYahfK2hnpJOGBvWVfaHvsUiPN40kS7 BvLRQUjYo2trEmq2YNI99bYfFJlzGztBEiK4grfoRMDRVavSxexuvY3IEBXWfcHT 7JRTcwPxwOIDyf6hqDa7WN90JwGXvf7TQnkVF54rYqn5Z/SkPvafGYM82CclDayh 9pUR4jF3nrKe7Ii/klVEhZNjiAyuEkrC1XbL8JIzqvZ6SBA7kbET4XYgh+7oEg77 bW51fqKEy1ej6cRcF4hf6YaeVg3DXAktvWWWKGzK2fZe48nLKw43hdu7WspoNG7o lNhXCXRlIKyH6pv/tdUy =WsXE -----END PGP SIGNATURE----- --=_T-00OrdGI7S8EnwxWySsbl8-- From owner-freebsd-hackers@freebsd.org Wed Sep 23 14:56:24 2020 Return-Path: Delivered-To: freebsd-hackers@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 DB76E3FC613 for ; Wed, 23 Sep 2020 14:56:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 4BxLpv6SWTz3SmK for ; Wed, 23 Sep 2020 14:56:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 08NEuFDm058211 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 23 Sep 2020 17:56:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 08NEuFDm058211 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 08NEuFZ6058210; Wed, 23 Sep 2020 17:56:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Sep 2020 17:56:15 +0300 From: Konstantin Belousov To: Alexander Leidinger Cc: freebsd-hackers@freebsd.org Subject: Re: RFC: copy_file_range(3) Message-ID: <20200923145615.GH2570@kib.kiev.ua> References: <20200923122401.Horde.uXmEqpCzVbCyXTuyukZeRwU@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200923122401.Horde.uXmEqpCzVbCyXTuyukZeRwU@webmail.leidinger.net> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4BxLpv6SWTz3SmK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [0.83 / 15.00]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.46)[0.457]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(0.37)[0.370]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.00)[0.001]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 14:56:24 -0000 On Wed, Sep 23, 2020 at 12:24:01PM +0200, Alexander Leidinger via freebsd-hackers wrote: > Quoting Rick Macklem (from Wed, 23 Sep 2020 01:18:18 > +0000): > > > Well, I ran some quick benchmarks using the attached programs, plus "cp" both > > before and with your copy_file_range() patch. > > copya - Does what I think your plan is above, with a limit of 2Mbytes > > for "len". > > copyb -Just uses copy_file_range() with 128Mbytes for "len". > > > > I first created the sparse file with createsparse.c. It is admittedly a > > worst case, > > creating alternating holes and data blocks of the minimum size supported by > > the file system. (I ran it on a UFS file system created with defaults, > > so the minimum > > hole size is 32Kbytes.) > > Not related to the topic of changing cp, but related to the topic of > copy_file_range: does nullfs support (as in pass-through to the underlying > FS) copy_file_range? Nullfs bypasses VOP_COPY_FILE_RANGE() same as any other multi-vp arg VOP. What makes you think it is different ? From owner-freebsd-hackers@freebsd.org Wed Sep 23 15:08:10 2020 Return-Path: Delivered-To: freebsd-hackers@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 AEEB23FC7F1 for ; Wed, 23 Sep 2020 15:08:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670083.outbound.protection.outlook.com [40.107.67.83]) (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 4BxM4T4z42z3Tfc; Wed, 23 Sep 2020 15:08:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IrI3FeO9jMQA9WIMGMq0Zc418JM2IGlWz0sveAPbM53Y6mvLj6uQktbtcff96+W+6rT3/6K1vPLydzoMrLRH0QYxITr1Z0+JgdWCsc7Jdu33YHQXeODMhRWoJjaB/lC8OSC3cikas1KE7VkRLvgJ0mO5TqZrqxmhk/fOJBXrCTZmKhxqUXEfe3ohaSddBeJvRU8TQmrK3HPGdPSWDgzzx8GI5RapEOGZ5SuM9/JeNhf51AJlwXBmqSfrV5OKUYRPlYumaDTo6YhBcfhdM8EGQFUALjEedm5xLrPCcq8DMFXeeXL7CPRDhMDId3rkl9GUY+9/jSGKB+kKO09u25JV5w== 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=MWXXjdPeKeWSE0LH90Sdc/miiCnCSkNuNZaFvpf8i+Q=; b=YnucZHsIXX9qCAqEqzSnMuVWUvLihm1IS9WOv0JXsMyrYcQshvqyMnEn526kULVbhVPNr/N8upOCo1TIKjN9+r9oZOrNGknCBw0H0cd75vefj28Rw+6tSAq7+QwDXcSI69KZ/3TOp2iV4/hr+MpG+xrVHaYFF7cew4pV7MWIRVgzv9+MYXqBbHgNFItX0vnLMI2TpYNUK14WAAmvbLB3rxgtXEdQcLrInQrjvam01szHajhOMFHOm9WFKtuwbuZu5hDxydnZoEcI+IalkfZF+pWodKm1vWvthxxRHw92uz4b4i8JWFpnXuVYTC17X135TEGWrH3mBfEN7XSCS07t2A== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MWXXjdPeKeWSE0LH90Sdc/miiCnCSkNuNZaFvpf8i+Q=; b=bhKZBi9G3rwxFW9TxhJTZprP9LDmaSqhg3+/9q8ytGf034ATsPMC4rmlrDPR0ZpRhbderFagMktRu4lTpaAER6IlZqO7U59ORA6k4oV4K6s4yXPiBgXF2TXaNF4RoRsxHYmOKO/PnPw/30sCoy/cwH2lvPwFEf9SabGsWyGB7caWwXa8yL77QrVHyQbnoy3aErk1s+KWP83MWvs/PvLjuzodxCimMqBKRTFfz3dYx4OEFcDAwkMC2xkZVFrDXkIVICW4Ftvg02M03ZeUPT6AtvueYVJK3F2qLffGk2l51x8+MVspRdpIc0HX3O1UYMpzIrZ9C3c9J3Ebj6Ql/JH2HQ== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTOPR0101MB2076.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:22::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15; Wed, 23 Sep 2020 15:08:08 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3391.027; Wed, 23 Sep 2020 15:08:08 +0000 From: Rick Macklem To: Alan Somers CC: FreeBSD Hackers , Konstantin Belousov Subject: Re: RFC: copy_file_range(3) Thread-Topic: RFC: copy_file_range(3) Thread-Index: AQHWj2Uep8NVOqCTP0KuS7h/nlgLPqlxrARqgAAEfICAAHAflYAAMOYAgAMOVByAAPKLRQ== Date: Wed, 23 Sep 2020 15:08:08 +0000 Message-ID: References: , , In-Reply-To: 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: 0bf24dec-a25c-4c2c-b4cb-08d85fd27ae4 x-ms-traffictypediagnostic: YTOPR0101MB2076: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jhUaZALHCd68Z467swM1ukuuwa0Fzr2qucQ+BWOmcxZoAjekeVP4bSn9YntbplNkshmhq3KEPzzZeKXSlK86LGz+jCI5Z7UbdJ+2it2uIh8qS4WtTxqZIfQNU781KUx7PwKNny/HV9lYqEZTVl+qOCjX0KYCSaUvnhO66ilai/jLkJ9Yioq8Xefnjm6XZF/NYD2m93dXm8nqHn+xFeA1aDZE/9hvWauufJsqrV2xZ9jOlvg19ZdRQ3mkWYvDcCqBHPVlVosp3FfZemtGtcddIeFn8LF1PqvPpCKl9ZWUsnWdHjfrqQbCCNuxRNI44m5o x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39850400004)(366004)(346002)(376002)(396003)(136003)(2906002)(4326008)(71200400001)(6506007)(54906003)(186003)(450100002)(9686003)(5660300002)(55016002)(6916009)(66446008)(52536014)(83380400001)(7696005)(66946007)(86362001)(478600001)(8936002)(33656002)(66556008)(316002)(66476007)(64756008)(8676002)(91956017)(2940100002)(786003)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: AtN9T5CSv1o0o6+vbmVkyjX1K5ZQ4l6c9Uwt0+XkCV5qj8n2YRTonAWDk/H9fVh3N2lmCTYhegfFcWaGNPfCOzD1yic9nUHeZ74CAZwGbpZnywxC2NxN2oWWYgb6QesUuNSTjN8jgWOEhJODOFT2Q35WoZzUu6WCwPckhmdhSnfM/bPfBsiFJ1nzH7CmkBbGhc8j8M82Z1pOlBGT7K0Wwb3cIfON2C2GNpSPFIgBJlMR0PcZ+ESf704n10EU48ICTjQRyQkMLGvKq5fTQhvDJCZz9LRrjPbKp+QaDuc0nKaUkpSoKyqGGEdzb2dWoQAnFE0ga8Z3EUBpfoeaCWgKiT71MvXqjrtT3uIlzUapZshOS5kPfSsgQEYB0FSdkERNSDBNHvDqv2eSWcKQM+gOTwUIG4YKzsxGR4Cpxb2pJdcbgFqXQjLlzVHJVSfg6qOEE2AhkVYnO+Wl9190GUV4LA3weORrf3s7LbIyou9pO3l1nNGLuDzwLNxuKk4033qtMCwpWyBJRaCpXxu39sSrGmOzXlhzjlDvul9vTO/1rvgIqmWf/+M4c9zR4v6dvw4DYr2c+wLYMDIScy7JuVdIpakrKTNxHEi7miQmBqbhnYU6q5WEoYHkwyzJK0PopjrHHBM1nV4KR4DBOVIiOX1+ve55tCmwa8dEVccsriKWygey5O6lFL9EtJSuPAHF/UHHKjk9sqSmznx6fPKL6wKVig== x-ms-exchange-transport-forked: True 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 0bf24dec-a25c-4c2c-b4cb-08d85fd27ae4 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2020 15:08:08.1475 (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: MlxsVGBVUTXLIKvl9c4MUVjvgCNrlRBmd+Ph10Xo7ZVZlsrTFJtQaw2f3snVyVMZxYygPS6pGctIUzM41H4sQw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2076 X-Rspamd-Queue-Id: 4BxM4T4z42z3Tfc X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=bhKZBi9G; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.83 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.46 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.003]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-0.995]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.83:from]; NEURAL_HAM_SHORT(-0.47)[-0.466]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.83:from] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 15:08:10 -0000 Rick Macklem wrote:=0A= >Alan Somers wrote:=0A= >[lots of stuff snipped]=0A= >>1) In order to quickly respond to a signal, a program must use a modest l= en with >>copy_file_range=0A= >For the programs you have mentioned, I think the only signal handling woul= d=0A= >be termination (C or SIGTERM if you prefer).=0A= >I'm not sure what is a reasonable response time for this.=0A= >I'd like to hear comments from others?=0A= >- 1sec, less than 1sec, a few seconds, ...=0A= >=0A= >> 2) If a hole is larger than len, that will cause vn_generic_copy_file_ra= nge to=0A= >> truncate the output file to the middle of the hole. Then, in the next i= nvocation,=0A= >> truncate it again to a larger size.=0A= >> 3) The result is a file that is not as sparse as the original.=0A= >Yes. So, the trick is to use the largest "len" you can live with, given ho= w long you=0A= >are willing to wait for signal processing.=0A= >=0A= >> For example, on UFS:=0A= >> $ truncate -s 1g sparsefile=0A= >Not a very interesting sparse file. I wrote a little program to create one= .=0A= >> $ cp sparsefile sparsefile2=0A= >> $ du -sh sparsefile*=0A= >> 96K sparsefile=0A= >> 32M sparsefile2=0A= Btw, this happens because, at least for UFS (not sure about other file=0A= systems), if you grow a file's size via VOP_SETATTR() of size, it allocates= a=0A= block at the new EOF, even though no data has been written there.=0A= --> This results in one block being allocated at the end of the range used= =0A= for a copy_file_range() call, if that file offset is within a hole.=0A= --> The larger the "len" argument, the less frequently it will occur.= =0A= =0A= >>=0A= >> My idea for a userland wrapper would solve this problem by using=0A= >> SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use copy_file_r= ange for=0A= >> everything else with a modest len. Alternatively, we could eliminate th= e need for=0A= >> the wrapper by enabling copy_file_range for every file system, and makin= g=0A= >> vn_generic_copy_file_range interruptible, so copy_file_range can be call= ed with=0A= >> large len without penalizing signal handling performance.=0A= >=0A= >Well, I ran some quick benchmarks using the attached programs, plus "cp" b= oth=0A= >before and with your copy_file_range() patch.=0A= >copya - Does what I think your plan is above, with a limit of 2Mbytes for = "len".=0A= >copyb -Just uses copy_file_range() with 128Mbytes for "len".=0A= >=0A= >I first created the sparse file with createsparse.c. It is admittedly a wo= rst case,=0A= >creating alternating holes and data blocks of the minimum size supported b= y=0A= >the file system. (I ran it on a UFS file system created with defaults, so = the minimum=0A= >>hole size is 32Kbytes.)=0A= >The file is 1Gbyte in size with an Allocation size of 524576 ("ls -ls").= =0A= >=0A= >I then ran copya, copyb, old-cp and new-cp. For NFS, I redid the mount bef= ore=0A= >each copy to avoid data caching in the client.=0A= >Here's what I got:=0A= > Elapsed time #RPCs Alloca= tion size ("ls -ls" on server)=0A= >NFSv4.2=0A= >copya 39.7sec 16384copy+32768seek 524576=0A= >copyb 10.2sec 104copy 52= 4576=0A= When I ran the tests I had vfs.nfs.maxcopyrange set to 128Mbytes on the=0A= server. However it was still the default of 10Mbytes on the client,=0A= so this test run used 10Mbytes per Copy. (I wondered why it did 104 Copyies= ?)=0A= With both set to 128Mbytes I got:=0A= copyb 10.0sec 8copy = 524576=0A= >old-cp 21.9sec 16384read+16384write 1048864=0A= >new-cp 10.5sec 1024copy 524= 576=0A= >=0A= >NFSv4.1=0A= >copya 21.8sec 16384read+16384write 1048864=0A= >copyb 21.0sec 16384read+16384write 1048864=0A= >old-cp 21.8sec 16384read+16384write 1048864=0A= >new-cp 21.4sec 16384read+16384write 1048864=0A= >=0A= >Local on the UFS file system=0A= >copya 9.2sec n/a = 524576=0A= This turns out to be just variability in the test. I get 7.9sec->9.2sec=0A= for runs of all three of copya, copyb and new-cp for UFS.=0A= I think it is caching related, since I wasn't unmounting/remounting the=0A= UFS file system between test runs.=0A= >copyb 8.0sec n/a = 524576=0A= >old-cp 15.9sec n/a = 1048864=0A= >new-cp 7.9sec n/a = 524576=0A= >=0A= >So, for a NFSv4.2 mount, using SEEK_DATA/SEEK_HOLE is definitely=0A= >a performance hit, due to all the RPC rtts.=0A= >Your patched "cp" does fine, although a larger "len" reduces the=0A= >RPC count against the server.=0A= >All variants using copy_file_range() retain the holes.=0A= >=0A= >For NFSv4.1, it (not surprisingly) doesn't matter, since only NFSv4.2=0A= >supports SEEK_DATA/SEEK_HOLE and VOP_COPY_FILE_RANGE().=0A= >=0A= >For UFS, everything using copy_file_range() works pretty well and=0A= >retains the holes.=0A= =0A= >Although "copya" is guaranteed to retain the holes, it does run noticably= =0A= >slower than the others. Not sure why? Does the extra SEEK_DATA/SEEK_HOLE= =0A= >syscalls cost that much?=0A= Ignore this. It was just variability in the test runs.=0A= =0A= >The limitation of not using SEEK_DATA/SEEK_HOLE is that you will not=0A= >retain holes that straddle the byte range copied by two subsequent=0A= >copy_file_range(2) calls.=0A= This statement is misleading. These holes are partially retained, but there= =0A= will be a block allocated (at least for UFS) at the boundary, due the prope= rty of=0A= growing a file via VOP_SETATTR(size) as noted above.=0A= =0A= >--> This can be minimized by using a large "len", but that large "len"=0A= > results in slower response to signal handling.=0A= I'm going to play with "len" to-day and come up with some numbers=0A= w.r.t. signal handling response time vs the copy_file_range() "len" argumen= t.=0A= =0A= >I've attached the little programs, so you can play with them.=0A= >(Maybe try different sparse schemes/sizes? It might be fun to=0A= > make the holes/blocks some random multiple of hole size up=0A= > to a limit?)=0A= >=0A= >rick=0A= >ps: In case he isn't reading hackers these days, I've added kib@=0A= > as a cc. He might know why UFS is 15% slower when SEEK_HOLE=0A= > SEEK_DATA is used.=0A= =0A= rick=0A= =0A= -Alan=0A= From owner-freebsd-hackers@freebsd.org Wed Sep 23 17:52:57 2020 Return-Path: Delivered-To: freebsd-hackers@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 6A1F2421458 for ; Wed, 23 Sep 2020 17:52:57 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oo1-f48.google.com (mail-oo1-f48.google.com [209.85.161.48]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BxQkc4VqWz3y9s; Wed, 23 Sep 2020 17:52:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oo1-f48.google.com with SMTP id z1so94866ooj.3; Wed, 23 Sep 2020 10:52:56 -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; bh=Xd9m/qwfyqgT4/vy2Tj7i/XHo2CULMby8+BqNHFwPnE=; b=N3uvq2XfMNNqSDVTlAIaLmXebLaPltGzfiee+f7X+ieKgKDSJ9EnB0aQOjFZFM/OxJ 21vYXDMcl5zitwtzNAkUtR/q0K9tVkp9gvFxqvMBSkzi1B5RsH5AKSBJI2EeeOTv9lcu Lec5DBeHNam1r1eL0Xjx7OUsKLF/S4kpbQ68VSmKfWzMfYOSbjkhm1eqEoDI3O7oAYy8 q3XS/nW0uUIXqf+xI0+yTyMRbhwqxMGygm2+r6lyFPd7skkGqvTII+BDM1MNpsOdzIxL WAxofuxEB8y8VAlTle+C91y+CEQjBLkZoXAcyOVF71Ai9KhGwtIjJbOM4KoslQ/wWDuS VhRg== X-Gm-Message-State: AOAM531y283rAq53DP7kbQd0MOiZpMQPXQRgQfLMVeUvaklOCfIpBJlx uPCnALPGUfPChnHRLaX2x8qDOJ3P1RApuaTDfUo5Cf+M X-Google-Smtp-Source: ABdhPJxJynFIdDdw8WLwX78CuVDxPCXjoYerlKPcQgoUvKtBz33duPU6SkPjZhqsVQVh3gAYOkLaM7Lfa7uCDsgomx4= X-Received: by 2002:a4a:e544:: with SMTP id s4mr634719oot.74.1600883575103; Wed, 23 Sep 2020 10:52:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Wed, 23 Sep 2020 11:52:43 -0600 Message-ID: Subject: Re: RFC: copy_file_range(3) To: Rick Macklem Cc: FreeBSD Hackers , Konstantin Belousov X-Rspamd-Queue-Id: 4BxQkc4VqWz3y9s X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.161.48 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.36 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[asomers]; 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.001]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.90)[-0.905]; RWL_MAILSPIKE_GOOD(0.00)[209.85.161.48:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.45)[-0.451]; RCVD_IN_DNSWL_NONE(0.00)[209.85.161.48:from]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 17:52:57 -0000 On Wed, Sep 23, 2020 at 9:08 AM Rick Macklem wrote: > Rick Macklem wrote: > >Alan Somers wrote: > >[lots of stuff snipped] > >>1) In order to quickly respond to a signal, a program must use a modest > len with >>copy_file_range > >For the programs you have mentioned, I think the only signal handling > would > >be termination (C or SIGTERM if you prefer). > >I'm not sure what is a reasonable response time for this. > >I'd like to hear comments from others? > >- 1sec, less than 1sec, a few seconds, ... > > > >> 2) If a hole is larger than len, that will cause > vn_generic_copy_file_range to > >> truncate the output file to the middle of the hole. Then, in the next > invocation, > >> truncate it again to a larger size. > >> 3) The result is a file that is not as sparse as the original. > >Yes. So, the trick is to use the largest "len" you can live with, given > how long you > >are willing to wait for signal processing. > > > >> For example, on UFS: > >> $ truncate -s 1g sparsefile > >Not a very interesting sparse file. I wrote a little program to create > one. > >> $ cp sparsefile sparsefile2 > >> $ du -sh sparsefile* > >> 96K sparsefile > >> 32M sparsefile2 > Btw, this happens because, at least for UFS (not sure about other file > systems), if you grow a file's size via VOP_SETATTR() of size, it > allocates a > block at the new EOF, even though no data has been written there. > --> This results in one block being allocated at the end of the range used > for a copy_file_range() call, if that file offset is within a hole. > --> The larger the "len" argument, the less frequently it will occur. > > >> > >> My idea for a userland wrapper would solve this problem by using > >> SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use > copy_file_range for > >> everything else with a modest len. Alternatively, we could eliminate > the need for > >> the wrapper by enabling copy_file_range for every file system, and > making > >> vn_generic_copy_file_range interruptible, so copy_file_range can be > called with > >> large len without penalizing signal handling performance. > > > >Well, I ran some quick benchmarks using the attached programs, plus "cp" > both > >before and with your copy_file_range() patch. > >copya - Does what I think your plan is above, with a limit of 2Mbytes for > "len". > >copyb -Just uses copy_file_range() with 128Mbytes for "len". > > > >I first created the sparse file with createsparse.c. It is admittedly a > worst case, > >creating alternating holes and data blocks of the minimum size supported > by > >the file system. (I ran it on a UFS file system created with defaults, so > the minimum > >>hole size is 32Kbytes.) > >The file is 1Gbyte in size with an Allocation size of 524576 ("ls -ls"). > > > >I then ran copya, copyb, old-cp and new-cp. For NFS, I redid the mount > before > >each copy to avoid data caching in the client. > >Here's what I got: > > Elapsed time #RPCs > Allocation size ("ls -ls" on server) > >NFSv4.2 > >copya 39.7sec 16384copy+32768seek 524576 > >copyb 10.2sec 104copy > 524576 > When I ran the tests I had vfs.nfs.maxcopyrange set to 128Mbytes on the > server. However it was still the default of 10Mbytes on the client, > so this test run used 10Mbytes per Copy. (I wondered why it did 104 > Copyies?) > With both set to 128Mbytes I got: > copyb 10.0sec 8copy > 524576 > >old-cp 21.9sec 16384read+16384write 1048864 > >new-cp 10.5sec 1024copy > 524576 > > > >NFSv4.1 > >copya 21.8sec 16384read+16384write 1048864 > >copyb 21.0sec 16384read+16384write 1048864 > >old-cp 21.8sec 16384read+16384write 1048864 > >new-cp 21.4sec 16384read+16384write 1048864 > > > >Local on the UFS file system > >copya 9.2sec n/a > 524576 > This turns out to be just variability in the test. I get 7.9sec->9.2sec > for runs of all three of copya, copyb and new-cp for UFS. > I think it is caching related, since I wasn't unmounting/remounting the > UFS file system between test runs. > >copyb 8.0sec n/a > 524576 > >old-cp 15.9sec n/a > 1048864 > >new-cp 7.9sec n/a > 524576 > > > >So, for a NFSv4.2 mount, using SEEK_DATA/SEEK_HOLE is definitely > >a performance hit, due to all the RPC rtts. > >Your patched "cp" does fine, although a larger "len" reduces the > >RPC count against the server. > >All variants using copy_file_range() retain the holes. > > > >For NFSv4.1, it (not surprisingly) doesn't matter, since only NFSv4.2 > >supports SEEK_DATA/SEEK_HOLE and VOP_COPY_FILE_RANGE(). > > > >For UFS, everything using copy_file_range() works pretty well and > >retains the holes. > > >Although "copya" is guaranteed to retain the holes, it does run noticably > >slower than the others. Not sure why? Does the extra SEEK_DATA/SEEK_HOLE > >syscalls cost that much? > Ignore this. It was just variability in the test runs. > > >The limitation of not using SEEK_DATA/SEEK_HOLE is that you will not > >retain holes that straddle the byte range copied by two subsequent > >copy_file_range(2) calls. > This statement is misleading. These holes are partially retained, but there > will be a block allocated (at least for UFS) at the boundary, due the > property of > growing a file via VOP_SETATTR(size) as noted above. > > >--> This can be minimized by using a large "len", but that large "len" > > results in slower response to signal handling. > I'm going to play with "len" to-day and come up with some numbers > w.r.t. signal handling response time vs the copy_file_range() "len" > argument. > > >I've attached the little programs, so you can play with them. > >(Maybe try different sparse schemes/sizes? It might be fun to > > make the holes/blocks some random multiple of hole size up > > to a limit?) > > > >rick > >ps: In case he isn't reading hackers these days, I've added kib@ > > as a cc. He might know why UFS is 15% slower when SEEK_HOLE > > SEEK_DATA is used. > So it sounds like your main point is that for file systems with special support, copy_file_range(2) is more efficient for many sparse files than SEEK_HOLE/SEEK_DATA. Sure, I buy that. And secondarily, you don't see any reason not to increase the len argument in commands like cp up to somewhere around 128 MB, delaying signal handling for about 1 second on a typical desktop (maybe set it lower on embedded arches). And you think it's fine to allow copy_file_range on devfs, as long as the len argument is clipped at some finite value. If we make all of those changes, are there any other reasons why the write/read fallback path would be needed? -Alan From owner-freebsd-hackers@freebsd.org Wed Sep 23 19:21:48 2020 Return-Path: Delivered-To: freebsd-hackers@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 61CD7424513 for ; Wed, 23 Sep 2020 19:21:48 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 4BxSj73mylz4DH6 for ; Wed, 23 Sep 2020 19:21:47 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165e4a.dip0.t-ipconnect.de [91.22.94.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id B7F13957; Wed, 23 Sep 2020 21:21:38 +0200 (CEST) Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id C03F67083; Wed, 23 Sep 2020 21:21:35 +0200 (CEST) Date: Wed, 23 Sep 2020 21:21:35 +0200 Message-ID: <20200923212135.Horde.KVi_zSxPaGuNqcGzm_Qxani@webmail.leidinger.net> From: Alexander Leidinger To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Subject: Re: RFC: copy_file_range(3) References: <20200923122401.Horde.uXmEqpCzVbCyXTuyukZeRwU@webmail.leidinger.net> <20200923145615.GH2570@kib.kiev.ua> In-Reply-To: <20200923145615.GH2570@kib.kiev.ua> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_cra2yUFAAPzMYOEMsTpbEue"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 4BxSj73mylz4DH6 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.82 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.05)[-1.046]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.015]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; NEURAL_SPAM_SHORT(0.35)[0.346]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.94.74:received] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 19:21:48 -0000 This message is in MIME format and has been PGP signed. --=_cra2yUFAAPzMYOEMsTpbEue Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Konstantin Belousov (from Wed, 23 Sep=20=20 2020=2017:56:15 +0300): > On Wed, Sep 23, 2020 at 12:24:01PM +0200, Alexander Leidinger via=20=20 >=20freebsd-hackers wrote: >> Quoting Rick Macklem (from Wed, 23 Sep 2020 01:18= :18 >> +0000): >> >> > Well, I ran some quick benchmarks using the attached programs,=20=20 >>=20plus "cp" both >> > before and with your copy_file_range() patch. >> > copya - Does what I think your plan is above, with a limit of 2Mbytes >> > for "len". >> > copyb -Just uses copy_file_range() with 128Mbytes for "len". >> > >> > I first created the sparse file with createsparse.c. It is admittedly = a >> > worst case, >> > creating alternating holes and data blocks of the minimum size=20=20 >>=20supported by >> > the file system. (I ran it on a UFS file system created with defaults, >> > so the minimum >> > hole size is 32Kbytes.) >> >> Not related to the topic of changing cp, but related to the topic of >> copy_file_range: does nullfs support (as in pass-through to the underlyi= ng >> FS) copy_file_range? > > Nullfs bypasses VOP_COPY_FILE_RANGE() same as any other multi-vp arg > VOP. What makes you think it is different ? I understand "bypass" as "does not handle copy_file_range". And from=20=20 what=20I was understanding in this discussion, each FS-driver needs to=20= =20 be=20modified to support copy_file_range. I've never looked into the=20=20 nullfs=20code (and VFS is for me some kind of object oriented interface=20= =20 into=20which FSes can plug into, with a generic "I can't do that" for=20=20 parts=20of the interface which needs a FS specific implementation in=20=20 case=20the FS doesn't provide this part), so I do not know how it=20=20 handles=20the "place A is a portal into place B". Naivly speaking I=20=20 would=20assume it translates a request for a specific path by modifying=20= =20 the=20path internally, but for that it needs to provide an. I do not=20=20 know=20how much meta-data needs to be handled / kept in memory /=20=20 generated=20for this. I had the options "maybe to much for a=20=20 pass-through",=20and "maybe not too much for a pass-through". To me it=20= =20 makes=20sense, that nullfs is able to handle this (I have a samba server=20= =20 in=20a jail which has some datasets mounted via nullfs, and the same=20=20 datasets=20are also mounted into other jails and served read-only via a=20= =20 webserver=20or other kinds of servers, and would be usefule if samba=20=20 could=20use copy_file_range on nullfs). You could argue that my question=20= =20 was=20more "is nullfs modified to handle copy_file_range", than "does it=20= =20 technically=20pass-through". Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_cra2yUFAAPzMYOEMsTpbEue Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJfa6A+AAoJEBINsJsD+NiG8FYQAIwJbnPLEpiKEhodr1Q36dpe LThlkX6JMEOI19PbEUBV/RPDq+vxR7cQtCrLtZXBtBhqC8zBXamCZsWC9AR7035w ZzHJXJJ+LzqmzA09X4Fo3+vPetX5rJP9HPLucDNcBXvzdv6O7mAxCcbAj/ZVuR0Z VMunq0uKz8ASutJtH65nemFTBWts665xK/7uzR0LO1MEiYxICa7Oreacu+pq0Ltt 5dZACMQgmVkYdrN/6jdGQWW7CHlgJ5NZtccAigIRLve4Y+phwhlAHxSZk0Lin7HF YKiEK/+2f32emdo8ezlFtXqO2SGHen1ZepBw2evjdwKl215E/nwh565nuIZOEknX Fp0JFY3h8tIXdY+cWPI99npM5eI7cDrOv4+bKt/Hf4+xTZde/kDrpTEagJXtlO95 g8dM3Xyw42MYtD3FHuJhWCT+IaDJZHIJd5iEDDO0uWAuHgQNazln0QAxW81KL5wJ fQG2HEmqFAr/GQXqzEpnPytcpl2n+Z3PeKNz6rEmWiwtzbrZuTyeRi9YZeafPCZF wK3EZIAdatHNjk2ukiUwvJ1ZSoTb6+QppXCkskzhBj/l98armTGpD+JrKRDgt3cu eK71XaBjrgSMb2ZQApVaoYMHA5jgyR1/OdukvIqQuQsBkN9lqqxqv3tmf5u2pRfv dnO8TGMF9rKKrBfjM1QW =3pKN -----END PGP SIGNATURE----- --=_cra2yUFAAPzMYOEMsTpbEue-- From owner-freebsd-hackers@freebsd.org Wed Sep 23 22:43:23 2020 Return-Path: Delivered-To: freebsd-hackers@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 C32A43E09F0 for ; Wed, 23 Sep 2020 22:43:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 4BxY9k3vJmz4SvX for ; Wed, 23 Sep 2020 22:43:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 08NMh8fU068290 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 24 Sep 2020 01:43:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 08NMh8fU068290 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 08NMh8gK068289; Thu, 24 Sep 2020 01:43:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Sep 2020 01:43:08 +0300 From: Konstantin Belousov To: Alexander Leidinger Cc: freebsd-hackers@freebsd.org Subject: Re: RFC: copy_file_range(3) Message-ID: <20200923224308.GK2570@kib.kiev.ua> References: <20200923122401.Horde.uXmEqpCzVbCyXTuyukZeRwU@webmail.leidinger.net> <20200923145615.GH2570@kib.kiev.ua> <20200923212135.Horde.KVi_zSxPaGuNqcGzm_Qxani@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200923212135.Horde.KVi_zSxPaGuNqcGzm_Qxani@webmail.leidinger.net> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4BxY9k3vJmz4SvX X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [0.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_MEDIUM(0.13)[0.126]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.08)[-0.079]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.06)[0.056]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 22:43:23 -0000 On Wed, Sep 23, 2020 at 09:21:35PM +0200, Alexander Leidinger wrote: > Quoting Konstantin Belousov (from Wed, 23 Sep 2020 > 17:56:15 +0300): > > > On Wed, Sep 23, 2020 at 12:24:01PM +0200, Alexander Leidinger via > > freebsd-hackers wrote: > > > Quoting Rick Macklem (from Wed, 23 Sep 2020 01:18:18 > > > +0000): > > > > > > > Well, I ran some quick benchmarks using the attached programs, > > > plus "cp" both > > > > before and with your copy_file_range() patch. > > > > copya - Does what I think your plan is above, with a limit of 2Mbytes > > > > for "len". > > > > copyb -Just uses copy_file_range() with 128Mbytes for "len". > > > > > > > > I first created the sparse file with createsparse.c. It is admittedly a > > > > worst case, > > > > creating alternating holes and data blocks of the minimum size > > > supported by > > > > the file system. (I ran it on a UFS file system created with defaults, > > > > so the minimum > > > > hole size is 32Kbytes.) > > > > > > Not related to the topic of changing cp, but related to the topic of > > > copy_file_range: does nullfs support (as in pass-through to the underlying > > > FS) copy_file_range? > > > > Nullfs bypasses VOP_COPY_FILE_RANGE() same as any other multi-vp arg > > VOP. What makes you think it is different ? > > I understand "bypass" as "does not handle copy_file_range". And from what I > was understanding in this discussion, each FS-driver needs to be modified to > support copy_file_range. I've never looked into the nullfs code (and VFS is > for me some kind of object oriented interface into which FSes can plug into, > with a generic "I can't do that" for parts of the interface which needs a FS > specific implementation in case the FS doesn't provide this part), so I do > not know how it handles the "place A is a portal into place B". Naivly > speaking I would assume it translates a request for a specific path by > modifying the path internally, but for that it needs to provide an. I do not > know how much meta-data needs to be handled / kept in memory / generated for > this. I had the options "maybe to much for a pass-through", and "maybe not > too much for a pass-through". To me it makes sense, that nullfs is able to > handle this (I have a samba server in a jail which has some datasets mounted > via nullfs, and the same datasets are also mounted into other jails and > served read-only via a webserver or other kinds of servers, and would be > usefule if samba could use copy_file_range on nullfs). You could argue that > my question was more "is nullfs modified to handle copy_file_range", than > "does it technically pass-through". Bypass mean that nullfs forwards the call to corresponding VOP of the lower vnode. This should be described in D&I book, also see the comment at the start of null_vnops.c (I did not rechecked it for accuracy). We have fallback VOP vector that is invoked when filesystem does not implement some VOP. In case of copy_file_range VOP, the slot is filled by vop_stdcopy_file_range() that is a wrapper around vn_generic_copy_file_range(). AFAIR, only NFS client implements non-default implementation for copy_file_range() VOP. So UFS/ZFS/msdosfs use vn_generic_copy_file_range(). All this assumes that invp and outvp belongs to the same filesystem. If they do not, as was in case of cp /dev/null something, vn_copy_file_range() directly invokes vn_generic_copy_file_range(). The later is a loop around VOP_READ() passing buffer to VOP_WRITE(), as somebody could reasonably expect. invokes From owner-freebsd-hackers@freebsd.org Thu Sep 24 00:00:02 2020 Return-Path: Delivered-To: freebsd-hackers@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 A37CB3E2EB0; Thu, 24 Sep 2020 00:00:02 +0000 (UTC) (envelope-from owner-freebsd-quarterly-calls@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 4BxZtB3MTlz4Y8M; Thu, 24 Sep 2020 00:00:02 +0000 (UTC) (envelope-from owner-freebsd-quarterly-calls@freebsd.org) Delivered-To: freebsd-quarterly-calls@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 D9FD33E2F92; Thu, 24 Sep 2020 00:00:00 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BxZt84tD1z4YDt; Thu, 24 Sep 2020 00:00:00 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1600905600; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc; bh=GsZkOQ98mtEG+Y4D3fU55qcSdX0+pLRfjUgDx/1c48s=; b=Ttk0QTntgtbDxsvDz6+dbk899U54DDlgnX1CcT2SPTtvlE+7M4wvwE/XJLMunRLX1LnzIQ hExhUzlWVboJdCvBcVm7BR5FRQyyRczKUQzb4BSSlh5ojDHBEDU4P7/IhUO8LCcochjsVi BiWd1/YjI53Jok2f7VO4C+QL4NO8b6YIMcC/KN5BDnxmxZtPQXvV6qkm8ipz1GGAp/Dq8C gs/riXBWRgbZgypTUSJ6FClCXk/BjxMCWTz7addFCPjX1qg3ACxLVu9E4R3f/B3/ln2FuK eHaWgLIJEzTGO0tbkbugzYEW/hDyF5dMKDOT/+Wgi77p3kGnsreYh2A9r8JbDw== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 9B8321953A; Thu, 24 Sep 2020 00:00:00 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: [LAST OFFICIAL REMINDER] Call for 2020Q3 quarterly status reports Message-Id: <20200924000000.9B8321953A@freefall.freebsd.org> Date: Thu, 24 Sep 2020 00:00:00 +0000 (UTC) From: Daniel Ebdrup Jensen ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1600905600; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc; bh=GsZkOQ98mtEG+Y4D3fU55qcSdX0+pLRfjUgDx/1c48s=; b=FkZfdhF1a6JX84Uqa8lqJh0iZo4oTxNwhkkKi9sC52mkkIdYRAM80T2BsO9HZkohKbub+m qwzxrGOS3mGo6exkJIw2unODx8EErXL2OBtEYnljPLY1wQfesS7yUrIUwl9Bc6IhFz6hWa tNmPUuvKJeJufVIQMqXbil0BwHEb91z9RVEFJxDGrhzEbbS8l8zqZd/AfAtiDB81h/t9gP +gMuXojWJS1Hi9LyhyaxL3ZGbwwlXc/wgX2Ig+wcKxzYGLVpo9yLY+ewW0TDaO14hA5mYF 3bM1UOis9iQzs+wXG+x1biGp9QiFdS/UCLkeTlNwPRbeTeaUKyjDlmb2IDc0sg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1600905600; a=rsa-sha256; cv=none; b=WH1PJKadEVrFu2s1qMxd85iOLEng16iOkVGmraSye+RqG4zNCFEWAjZpiL3BLCH59V16Lj 6Wgq+qWMBY2RK4/VnIwP5xNIyHET6c6TDzMF2iZ23tolxEQQauXZz2r5iXWtbFrxsTkum7 NJFlhrQlBhpSTSFSWDFU/TKWhsuhqhsw4q9YzhNQz+iC89fXSOCFiZALlovRZYdRyYTkid NHieaON2zKeiTvCWTZPpysEg7KNwrnannybvkzQXwF2/ipdFejunZNHgQjhhNO/KpwAL/t St1E6WIL13i3C/TGunuH8olHwRXoenq+KHqthLlN07nSzXsoyVlgojrDg+VltQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-quarterly-calls@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-quarterly-calls@freebsd.org Sender: owner-freebsd-quarterly-calls@freebsd.org X-Mailman-Approved-At: Thu, 24 Sep 2020 01:20:23 +0000 X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 00:00:02 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is October, 1st 2020 for work done since the last round of Quarterly Reports: July 2020 - September 2020. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the Markdown template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md We look forward to seeing your 2020Q3 reports! Thanks, Daniel Ebdrup Jensen (on behalf of quarterly@) _______________________________________________ freebsd-quarterly-calls@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls To unsubscribe, send any mail to "freebsd-quarterly-calls-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Thu Sep 24 06:38:26 2020 Return-Path: Delivered-To: freebsd-hackers@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 2F1C53EE20B for ; Thu, 24 Sep 2020 06:38:26 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 4Bxljr5Yk6z40Gb for ; Thu, 24 Sep 2020 06:38:24 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p508d59c0.dip0.t-ipconnect.de [80.141.89.192]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id BF13D1070; Thu, 24 Sep 2020 08:38:20 +0200 (CEST) Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 38D8C7088; Thu, 24 Sep 2020 08:38:02 +0200 (CEST) Date: Thu, 24 Sep 2020 08:38:01 +0200 Message-ID: <20200924083801.Horde.AFG5vwsVvqadT4ehn1ol2q1@webmail.leidinger.net> From: Alexander Leidinger To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Subject: Re: RFC: copy_file_range(3) References: <20200923122401.Horde.uXmEqpCzVbCyXTuyukZeRwU@webmail.leidinger.net> <20200923145615.GH2570@kib.kiev.ua> <20200923212135.Horde.KVi_zSxPaGuNqcGzm_Qxani@webmail.leidinger.net> <20200923224308.GK2570@kib.kiev.ua> In-Reply-To: <20200923224308.GK2570@kib.kiev.ua> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_Vy10cXXb7UE2k-OW4Xz6sJN"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Rspamd-Queue-Id: 4Bxljr5Yk6z40Gb X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.55 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-0.97)[-0.967]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.02)[-1.015]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-0.47)[-0.465]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; RECEIVED_SPAMHAUS_PBL(0.00)[80.141.89.192:received] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 06:38:26 -0000 This message is in MIME format and has been PGP signed. --=_Vy10cXXb7UE2k-OW4Xz6sJN Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Konstantin Belousov (from Thu, 24 Sep=20=20 2020=2001:43:08 +0300): > Bypass mean that nullfs forwards the call to corresponding VOP of the > lower vnode. [...] > AFAIR, only NFS client implements non-default implementation for > copy_file_range() VOP. So UFS/ZFS/msdosfs use vn_generic_copy_file_range= (). [...] Great! Thanks for the info / explanation. Bye, Alexander --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_Vy10cXXb7UE2k-OW4Xz6sJN Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJfbD7JAAoJEBINsJsD+NiG4LkP/inNNfOQ/eNPpTZ8cNLqwBHD 7CtISDHRo+WJZpy0X4S17u/dNV5LsN/u1FVpLQsg9hFgkVBWUhO7Xkp6/cc1abcE mTprJgr7A5Qp7w/r9bH3fCjp2Xc5RdnJHv6urKt0hhz5HE9TNwcVZDxwAO0YkWjt dNCzEz13tOfBNR3UbFOXM//7x7Df+Y46vd6h1H0KmUA3h+K+ojn6V+17d6ti4vjg qNdoieQBJZzlUdosErFDOZygXCC7fEaNb24swYR4J6ZthrmUPOUJCX7eiE/3+uW3 /n8TD81j8QMZvdY57WwLLeVp6Xfu0Ga9V/5G8PVsNsP9m3Ooox15H7n+pW8RKdM7 KN5noBTichU2boQQgfWpMffk1ANZimahY+h6b04lXR7f7PzVesHEYoONUiW7LZm4 DU/8XTLZzkx4KLH5Lk+x3yaqFXz758Aj1RHnEvmUQz3n5wyjsz6APLYzBuozwtbs bGmvLhjtOn/gh85rEMZ0UnZ3Cd7SuTk2cN7rEUEJ54LZhTB5i8bIjUL1ehAHEotn 6DKnlayfgs7Q+VcevwhyYKqOoz4aXu/2FTDTZzD86bh6koFwt5vT5wZclzSVIhPG 3NAOaAhZrHM6jC8mKU1G/WJ7vLM0SauI7dLKrC4YJ/iB1khoKxRSrdqrERwn759u OTNJAipm/MiZ0Yq7eQOk =FpZZ -----END PGP SIGNATURE----- --=_Vy10cXXb7UE2k-OW4Xz6sJN-- From owner-freebsd-hackers@freebsd.org Fri Sep 25 16:26:47 2020 Return-Path: Delivered-To: freebsd-hackers@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 7B1863FBF43 for ; Fri, 25 Sep 2020 16:26:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0607.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::607]) (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 4ByckG1yddz4Brq; Fri, 25 Sep 2020 16:26:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W2Ivkd3vLzmuP3cM9hIgVRX+/kik3qKHGRpL3Lw2pEWXOpzkv//ksDtPLReWl2qibGqCr8oLkeu1or27eWq1VsXiBheJHdR1/jz25b2mxY+UqKQBOazLn50wliu4OBK+/MyykFOZxsnRfKuQsAhvjQ2mAc5StK7YhgmeA7P+kTpS25paiHVBFmZSLXDG3Hw2ILq22bQ3iRxUJhYd6iPOy9JPcl9bjtUunWe6THirTmCqY2hnrCTdo2qWstZd28+hMO/GpkadmlVPQuspThSaJ8nQFrTMPf6TBz9n5Y7gNoqldJ36uhdSAqvZYps7oLaafgL5gFs7erwsFDrRakm4Lg== 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=91Hh+XuAsjz/Mbqvc+elDIvh1f5ZWzVobjpfx/h4waw=; b=VApvU5BixZsFsFEMq/R/n+EHsZJYOUXQAsdUiV5Ypy05sLvyZfYg94wlZQrYGu4EKjBPz6bEbdRgnp42ng0FC8JgmhPyYbcHezIjmpmpFWMMtm9sojaEt0jz6n9TFa7eXslFpQye52JZ5UNBHSgfdVp4Hm35KXFgc7LUJ1DStbYGOjaq8V/mo0wMppKds7g8wDSFR3j+5fdalXMzfDdHjS7+2E5MoDgSy61B7eItJXIFb7fOLpHrdom4noXbepi5EFsyQ7sjOhoMveAgb9XDBZbnN/FIlqaOeUTJ8oQAtoG5Mubtk3xq62/aMazR2cvsGNT7nps5EMBqcrWaTk3vrQ== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=91Hh+XuAsjz/Mbqvc+elDIvh1f5ZWzVobjpfx/h4waw=; b=bSH1bksA5WlO1HmX1Ol5WJr7i/uMN2ME9TyuykmAq+tcV8+knga0xurbIzoWCyGwINgFo28UF0mbI5Xh6pYk21Az/PGiv941OBmFFmUPNcvWTfDjjdho5lmRkQYrrHXnkuXdK1TaRv6unPHE+gm0oNkYIHCJdHB/A6RTUXPcv+ZTw5x5Qt8o1W++aCd5r8s+KIVFfTLoCC6AK3jwWaFJ5nmrU57sUYQC4fFT8pyfTnIJgghAU2N//7QZzE9GkrRIvvw36pQl/CqCvDALN2C0UegoDOvE3+osQvqe4LXa3DRT75ITrnEarGDewOmPlRGCujen9slraSS69cHewlA5Hg== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTXPR0101MB1072.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:4::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Fri, 25 Sep 2020 16:26:43 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3412.024; Fri, 25 Sep 2020 16:26:43 +0000 From: Rick Macklem To: Alan Somers CC: FreeBSD Hackers , Konstantin Belousov Subject: Re: RFC: copy_file_range(3) Thread-Topic: RFC: copy_file_range(3) Thread-Index: AQHWj2Uep8NVOqCTP0KuS7h/nlgLPqlxrARqgAAEfICAAHAflYAAMOYAgAMOVByAAPKLRYAAM36AgAMJ89Y= Date: Fri, 25 Sep 2020 16:26:43 +0000 Message-ID: References: , In-Reply-To: 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: 79bc0b8a-9a5b-4c4b-9e5c-08d8616fca67 x-ms-traffictypediagnostic: YTXPR0101MB1072: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CHczfN8iToRE3yfuhMNG5WirCB/2U0ryCoNP0/a6IKW6U+rRq/kL1JDpFIfCZZtCI2a6BBbAQqsIrsuXJQv1ejsNzqSR3d8ViFhY34Pa51ASwKYaZdaZ2qq/vvGRG7s9VH50WaP9PmR1viMNJD1EHHWA3z2PJa6A0mK+92DlL+Y0D0ujTWBvlVKX8+JGZyk4DpKuAq5fjRFuXUUEkOQOGFRmHt8JWxAu3Apc+CFOnx3obV0FBbremp8xgHR1iB4gD5985/1X2U/s99jdCgcQUMVUDGqeEqFZbLkXYm21DULV4aHGVbQPnXsuKnMP59dtrPfi6yMV267Fn8Mi7TphXvRsD0s56STkeKNfJWGlyIjrRcnIlq0xxzzad/1HMhNs x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(396003)(366004)(346002)(39860400002)(376002)(33656002)(478600001)(76116006)(6916009)(86362001)(4326008)(66446008)(64756008)(450100002)(66556008)(66476007)(66946007)(91956017)(186003)(52536014)(71200400001)(55016002)(8936002)(316002)(53546011)(9686003)(6506007)(8676002)(2906002)(786003)(5660300002)(83380400001)(7696005)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: piimSfwMhFJvOcB6t/9U8vqDZFg8mII4H8iDs/dmArHZwM+k6yjLXRG9h3dENDwlgaUEXZkjmmUCAO3ECLxbrboVIMolPLPWQmYQyegj9ad32OVT0KUkTv69g8MNXBTOcMp74usnINFGzeZWmHeK8+PH5rtO2QdTMPY3gDlBdh8nyphia8OeB4SB+VYXO+BVKBV19lN4FhzIn+/DXE0EkkH7SnZrRyu0ADDTha3pwrQHJngROLYSEj15nYRoO0GMUfj0qyMiWA9GczXpTMZT6fvymtWWEAAxoIbN8U7SKw0/243a4G7Ky4ztQz2vOk5wwphv0H2hHik/Yn5QLjx5KZjnnLJlzsoItr2/Z6rdATNNQYeHR40ibfGqBG2t6Jt/61H/DqmZuCBPo/vH+Z5/2DnKiUVrRqjsVFcVPw/Sd9SrGxLmTT+1YdkGQ95XrYMSBnqqJhyJeL5hZ5m5ONAjj6th/jxKHOfqekqS3AAFQo9agKP4/Gy6H0lULuDT1zxjDDqNFBsy0MT2KgZKu8GigdG7smat+wEcmMjnK1MjJeybMx4T3SPXCSvh0+0ylo4FHGqUaAeFxCQMAm1xJzQYHnd8RF4ogOzMtHKvz7bAzD+YKon2gtdsfuSfvM2VBlzDEp9ar9OGl5bA/Z36Ajb1Q1CU0TB71ZYRCaTm8KNnQALWRFNxcRDY6nWKssevMNn/nRlD3+1bMiyzE+tumylGCA== x-ms-exchange-transport-forked: True 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 79bc0b8a-9a5b-4c4b-9e5c-08d8616fca67 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2020 16:26:43.7168 (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: cHuIjywY/+XJqw6J8IxRNUejFJMWF/w4uarHalARFxnfC3hm5q4ghPTzeC6uNdKqlvBwFkOvCq8pjpvmRH2FOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB1072 X-Rspamd-Queue-Id: 4ByckG1yddz4Brq X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=bSH1bksA; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5d::607 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.56 / 15.00]; NEURAL_HAM_MEDIUM(-1.01)[-1.006]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.01)[-1.014]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-0.54)[-0.536]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 16:26:47 -0000 [the indentation seems to be a bit messed up, so I'll skip to near the end.= ..]=0A= On Wed, Sep 23, 2020 at 9:08 AM Rick Macklem > wrote:=0A= Rick Macklem wrote:=0A= >Alan Somers wrote:=0A= >[lots of stuff snipped]=0A= >>1) In order to quickly respond to a signal, a program must use a modest l= en with >>copy_file_range=0A= >For the programs you have mentioned, I think the only signal handling woul= d=0A= >be termination (C or SIGTERM if you prefer).=0A= >I'm not sure what is a reasonable response time for this.=0A= >I'd like to hear comments from others?=0A= >- 1sec, less than 1sec, a few seconds, ...=0A= >=0A= >> 2) If a hole is larger than len, that will cause vn_generic_copy_file_ra= nge to=0A= >> truncate the output file to the middle of the hole. Then, in the next i= nvocation,=0A= >> truncate it again to a larger size.=0A= >> 3) The result is a file that is not as sparse as the original.=0A= >Yes. So, the trick is to use the largest "len" you can live with, given ho= w long you=0A= >are willing to wait for signal processing.=0A= >=0A= >> For example, on UFS:=0A= >> $ truncate -s 1g sparsefile=0A= >Not a very interesting sparse file. I wrote a little program to create one= .=0A= >> $ cp sparsefile sparsefile2=0A= >> $ du -sh sparsefile*=0A= >> 96K sparsefile=0A= >> 32M sparsefile2=0A= Btw, this happens because, at least for UFS (not sure about other file=0A= systems), if you grow a file's size via VOP_SETATTR() of size, it allocates= a=0A= block at the new EOF, even though no data has been written there.=0A= --> This results in one block being allocated at the end of the range used= =0A= for a copy_file_range() call, if that file offset is within a hole.=0A= --> The larger the "len" argument, the less frequently it will occur.= =0A= =0A= >>=0A= >> My idea for a userland wrapper would solve this problem by using=0A= >> SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use copy_file_r= ange for=0A= >> everything else with a modest len. Alternatively, we could eliminate th= e need for=0A= >> the wrapper by enabling copy_file_range for every file system, and makin= g=0A= >> vn_generic_copy_file_range interruptible, so copy_file_range can be call= ed with=0A= >> large len without penalizing signal handling performance.=0A= >=0A= >Well, I ran some quick benchmarks using the attached programs, plus "cp" b= oth=0A= >before and with your copy_file_range() patch.=0A= >copya - Does what I think your plan is above, with a limit of 2Mbytes for = "len".=0A= >copyb -Just uses copy_file_range() with 128Mbytes for "len".=0A= >=0A= >I first created the sparse file with createsparse.c. It is admittedly a wo= rst case,=0A= >creating alternating holes and data blocks of the minimum size supported b= y=0A= >the file system. (I ran it on a UFS file system created with defaults, so = the minimum=0A= >>hole size is 32Kbytes.)=0A= >The file is 1Gbyte in size with an Allocation size of 524576 ("ls -ls").= =0A= >=0A= >I then ran copya, copyb, old-cp and new-cp. For NFS, I redid the mount bef= ore=0A= >each copy to avoid data caching in the client.=0A= >Here's what I got:=0A= > Elapsed time #RPCs Alloca= tion size ("ls -ls" on server)=0A= >NFSv4.2=0A= >copya 39.7sec 16384copy+32768seek 524576=0A= >copyb 10.2sec 104copy 52= 4576=0A= When I ran the tests I had vfs.nfs.maxcopyrange set to 128Mbytes on the=0A= server. However it was still the default of 10Mbytes on the client,=0A= so this test run used 10Mbytes per Copy. (I wondered why it did 104 Copyies= ?)=0A= With both set to 128Mbytes I got:=0A= copyb 10.0sec 8copy = 524576=0A= >old-cp 21.9sec 16384read+16384write 1048864=0A= >new-cp 10.5sec 1024copy 524= 576=0A= >=0A= >NFSv4.1=0A= >copya 21.8sec 16384read+16384write 1048864=0A= >copyb 21.0sec 16384read+16384write 1048864=0A= >old-cp 21.8sec 16384read+16384write 1048864=0A= >new-cp 21.4sec 16384read+16384write 1048864=0A= >=0A= >Local on the UFS file system=0A= >copya 9.2sec n/a = 524576=0A= This turns out to be just variability in the test. I get 7.9sec->9.2sec=0A= for runs of all three of copya, copyb and new-cp for UFS.=0A= I think it is caching related, since I wasn't unmounting/remounting the=0A= UFS file system between test runs.=0A= >copyb 8.0sec n/a = 524576=0A= >old-cp 15.9sec n/a = 1048864=0A= >new-cp 7.9sec n/a = 524576=0A= >=0A= >So, for a NFSv4.2 mount, using SEEK_DATA/SEEK_HOLE is definitely=0A= >a performance hit, due to all the RPC rtts.=0A= >Your patched "cp" does fine, although a larger "len" reduces the=0A= >RPC count against the server.=0A= >All variants using copy_file_range() retain the holes.=0A= >=0A= >For NFSv4.1, it (not surprisingly) doesn't matter, since only NFSv4.2=0A= >supports SEEK_DATA/SEEK_HOLE and VOP_COPY_FILE_RANGE().=0A= >=0A= >For UFS, everything using copy_file_range() works pretty well and=0A= >retains the holes.=0A= =0A= >Although "copya" is guaranteed to retain the holes, it does run noticably= =0A= >slower than the others. Not sure why? Does the extra SEEK_DATA/SEEK_HOLE= =0A= >syscalls cost that much?=0A= Ignore this. It was just variability in the test runs.=0A= =0A= >The limitation of not using SEEK_DATA/SEEK_HOLE is that you will not=0A= >retain holes that straddle the byte range copied by two subsequent=0A= >copy_file_range(2) calls.=0A= This statement is misleading. These holes are partially retained, but there= =0A= will be a block allocated (at least for UFS) at the boundary, due the prope= rty of=0A= growing a file via VOP_SETATTR(size) as noted above.=0A= =0A= >--> This can be minimized by using a large "len", but that large "len"=0A= > results in slower response to signal handling.=0A= I'm going to play with "len" to-day and come up with some numbers=0A= w.r.t. signal handling response time vs the copy_file_range() "len" argumen= t.=0A= =0A= >I've attached the little programs, so you can play with them.=0A= >(Maybe try different sparse schemes/sizes? It might be fun to=0A= > make the holes/blocks some random multiple of hole size up=0A= > to a limit?)=0A= >=0A= >rick=0A= >ps: In case he isn't reading hackers these days, I've added kib@=0A= > as a cc. He might know why UFS is 15% slower when SEEK_HOLE=0A= > SEEK_DATA is used.=0A= Alan Somers wrote:=0A= > So it sounds like your main point is that for file systems with special s= upport, =0A= > copy_file_range(2) is more efficient for many sparse files than =0A= > SEEK_HOLE/SEEK_DATA.=0A= Well, for NFSv4.2 this is true. Who knows w.r.t. others in the future.=0A= =0A= > Sure, I buy that. And secondarily, you don't see any reason not to incr= ease the=0A= > len argument in commands like cp up to somewhere around 128 MB, delaying = =0A= > signal handling for about 1 second on a typical desktop (maybe set it low= er on =0A= > embedded arches).=0A= When I did some testing on my hardware (laptops with slow spinning disks),= =0A= I got up to about 2sec delay for 128Mbytes and up to about 1sec delay for= =0A= 64Mbyes. I got a post that suggested that 1sec should be the target and=0A= haven't heard differently from anyone else.=0A= =0A= Currently, there is a sysctl for NFS that clips the size of a copy_file_ran= ge(),=0A= so that RPC response is reasonable (1sec or less).=0A= Maybe that sysctl should be replaced with a generic one for copy_file_range= ()=0A= with a default of 64->128Mbytes. (I might make NFS use 1/2 of the sysctl=0A= value, since the RPC response time shouldn't exceed 1sec.)=0A= Does this sound reasonable?=0A= =0A= > And you think it's fine to allow copy_file_range on devfs, as long as th= e len =0A= > argument is clipped at some finite value. If we make all of those change= s, are=0A= > there any other reasons why the write/read fallback path would be needed= ?=0A= I'm on the fence w.r.t. this one. I understand why you would prefer a call = that=0A= worked for special files, but I also like the idea that it is "Linux compat= ible".=0A= =0A= I'd like to hear feedback from others on this.=0A= Maybe I'll try asking this question separately on freebsd-current@ and=0A= see if I can get others to respond.=0A= =0A= rick'=0A= =0A= -Alan=0A= From owner-freebsd-hackers@freebsd.org Fri Sep 25 16:55:06 2020 Return-Path: Delivered-To: freebsd-hackers@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 7EAC13FC7B1 for ; Fri, 25 Sep 2020 16:55:06 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BydLx3t52z4DbF; Fri, 25 Sep 2020 16:55:05 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f50.google.com with SMTP id n61so2908322ota.10; Fri, 25 Sep 2020 09:55:05 -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; bh=DeFW8Cv12kXjVRCtG17eR+2TP0JIc54b+q/ErEmZeSo=; b=qbUuAmtlKk51d+1J+jTqj1IY3fCqwLIBZbErjFpr7oD2BRFnbVu8ng7uyUfCH0EB7z SHRB9OVjVckB1dvMM+jxg35+B4/KvERtJVbP4h/nqzFv2T+jy0ZAYXESomPl/2ZPeSG6 6otS1wvJ24KKYW7PPYRQY4OS9trLQk+ezUXjuZtSZOuckrgPIGaHcxDUG8QfyL6Y1F2F vp6n62vTRMZSdT87g31pFGx+skBb3R6OEWo5yKYXYbqvS9s093Gznm+gLHf+c0cRdHYa xTuftlnTcc1iNH2rEkL5dUIubVFSe3LL+kolSlQsRgccudVWnQJJrC6tKNKhBwc3LInd EUmA== X-Gm-Message-State: AOAM532/yBbgizg+NxUh6i7fU+mr/wqmRAlGZNDWsEh4dTBdf+ckPvof /zf0fZzpkf8/Vkxqjzi8c9uBkATnYPbg7X6z6Gk= X-Google-Smtp-Source: ABdhPJy1ViqXPzkLKq13qRFDTY+1hodH+cBTZiepUnRhZzdki6GX3h25kmcqcQDwYL0/w9sI4iYb1hgeS9qCh1iE32w= X-Received: by 2002:a9d:758b:: with SMTP id s11mr866945otk.251.1601052904370; Fri, 25 Sep 2020 09:55:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Fri, 25 Sep 2020 10:54:53 -0600 Message-ID: Subject: Re: RFC: copy_file_range(3) To: Rick Macklem Cc: FreeBSD Hackers , Konstantin Belousov X-Rspamd-Queue-Id: 4BydLx3t52z4DbF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.50 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.46 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.02)[-1.016]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.50:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.41)[-0.405]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.50:from]; NEURAL_HAM_MEDIUM(-1.04)[-1.037]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 16:55:06 -0000 On Fri, Sep 25, 2020 at 10:26 AM Rick Macklem wrote: > [the indentation seems to be a bit messed up, so I'll skip to near the > end...] > On Wed, Sep 23, 2020 at 9:08 AM Rick Macklem rmacklem@uoguelph.ca>> wrote: > Rick Macklem wrote: > >Alan Somers wrote: > >[lots of stuff snipped] > >>1) In order to quickly respond to a signal, a program must use a modest > len with >>copy_file_range > >For the programs you have mentioned, I think the only signal handling > would > >be termination (C or SIGTERM if you prefer). > >I'm not sure what is a reasonable response time for this. > >I'd like to hear comments from others? > >- 1sec, less than 1sec, a few seconds, ... > > > >> 2) If a hole is larger than len, that will cause > vn_generic_copy_file_range to > >> truncate the output file to the middle of the hole. Then, in the next > invocation, > >> truncate it again to a larger size. > >> 3) The result is a file that is not as sparse as the original. > >Yes. So, the trick is to use the largest "len" you can live with, given > how long you > >are willing to wait for signal processing. > > > >> For example, on UFS: > >> $ truncate -s 1g sparsefile > >Not a very interesting sparse file. I wrote a little program to create > one. > >> $ cp sparsefile sparsefile2 > >> $ du -sh sparsefile* > >> 96K sparsefile > >> 32M sparsefile2 > Btw, this happens because, at least for UFS (not sure about other file > systems), if you grow a file's size via VOP_SETATTR() of size, it > allocates a > block at the new EOF, even though no data has been written there. > --> This results in one block being allocated at the end of the range used > for a copy_file_range() call, if that file offset is within a hole. > --> The larger the "len" argument, the less frequently it will occur. > > >> > >> My idea for a userland wrapper would solve this problem by using > >> SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use > copy_file_range for > >> everything else with a modest len. Alternatively, we could eliminate > the need for > >> the wrapper by enabling copy_file_range for every file system, and > making > >> vn_generic_copy_file_range interruptible, so copy_file_range can be > called with > >> large len without penalizing signal handling performance. > > > >Well, I ran some quick benchmarks using the attached programs, plus "cp" > both > >before and with your copy_file_range() patch. > >copya - Does what I think your plan is above, with a limit of 2Mbytes for > "len". > >copyb -Just uses copy_file_range() with 128Mbytes for "len". > > > >I first created the sparse file with createsparse.c. It is admittedly a > worst case, > >creating alternating holes and data blocks of the minimum size supported > by > >the file system. (I ran it on a UFS file system created with defaults, so > the minimum > >>hole size is 32Kbytes.) > >The file is 1Gbyte in size with an Allocation size of 524576 ("ls -ls"). > > > >I then ran copya, copyb, old-cp and new-cp. For NFS, I redid the mount > before > >each copy to avoid data caching in the client. > >Here's what I got: > > Elapsed time #RPCs > Allocation size ("ls -ls" on server) > >NFSv4.2 > >copya 39.7sec 16384copy+32768seek 524576 > >copyb 10.2sec 104copy > 524576 > When I ran the tests I had vfs.nfs.maxcopyrange set to 128Mbytes on the > server. However it was still the default of 10Mbytes on the client, > so this test run used 10Mbytes per Copy. (I wondered why it did 104 > Copyies?) > With both set to 128Mbytes I got: > copyb 10.0sec 8copy > 524576 > >old-cp 21.9sec 16384read+16384write 1048864 > >new-cp 10.5sec 1024copy > 524576 > > > >NFSv4.1 > >copya 21.8sec 16384read+16384write 1048864 > >copyb 21.0sec 16384read+16384write 1048864 > >old-cp 21.8sec 16384read+16384write 1048864 > >new-cp 21.4sec 16384read+16384write 1048864 > > > >Local on the UFS file system > >copya 9.2sec n/a > 524576 > This turns out to be just variability in the test. I get 7.9sec->9.2sec > for runs of all three of copya, copyb and new-cp for UFS. > I think it is caching related, since I wasn't unmounting/remounting the > UFS file system between test runs. > >copyb 8.0sec n/a > 524576 > >old-cp 15.9sec n/a > 1048864 > >new-cp 7.9sec n/a > 524576 > > > >So, for a NFSv4.2 mount, using SEEK_DATA/SEEK_HOLE is definitely > >a performance hit, due to all the RPC rtts. > >Your patched "cp" does fine, although a larger "len" reduces the > >RPC count against the server. > >All variants using copy_file_range() retain the holes. > > > >For NFSv4.1, it (not surprisingly) doesn't matter, since only NFSv4.2 > >supports SEEK_DATA/SEEK_HOLE and VOP_COPY_FILE_RANGE(). > > > >For UFS, everything using copy_file_range() works pretty well and > >retains the holes. > > >Although "copya" is guaranteed to retain the holes, it does run noticably > >slower than the others. Not sure why? Does the extra SEEK_DATA/SEEK_HOLE > >syscalls cost that much? > Ignore this. It was just variability in the test runs. > > >The limitation of not using SEEK_DATA/SEEK_HOLE is that you will not > >retain holes that straddle the byte range copied by two subsequent > >copy_file_range(2) calls. > This statement is misleading. These holes are partially retained, but there > will be a block allocated (at least for UFS) at the boundary, due the > property of > growing a file via VOP_SETATTR(size) as noted above. > > >--> This can be minimized by using a large "len", but that large "len" > > results in slower response to signal handling. > I'm going to play with "len" to-day and come up with some numbers > w.r.t. signal handling response time vs the copy_file_range() "len" > argument. > > >I've attached the little programs, so you can play with them. > >(Maybe try different sparse schemes/sizes? It might be fun to > > make the holes/blocks some random multiple of hole size up > > to a limit?) > > > >rick > >ps: In case he isn't reading hackers these days, I've added kib@ > > as a cc. He might know why UFS is 15% slower when SEEK_HOLE > > SEEK_DATA is used. > Alan Somers wrote: > > So it sounds like your main point is that for file systems with special > support, > > copy_file_range(2) is more efficient for many sparse files than > > SEEK_HOLE/SEEK_DATA. > Well, for NFSv4.2 this is true. Who knows w.r.t. others in the future. > > > Sure, I buy that. And secondarily, you don't see any reason not to > increase the > > len argument in commands like cp up to somewhere around 128 MB, delaying > > signal handling for about 1 second on a typical desktop (maybe set it > lower on > > embedded arches). > When I did some testing on my hardware (laptops with slow spinning disks), > I got up to about 2sec delay for 128Mbytes and up to about 1sec delay for > 64Mbyes. I got a post that suggested that 1sec should be the target and > haven't heard differently from anyone else. > > Currently, there is a sysctl for NFS that clips the size of a > copy_file_range(), > so that RPC response is reasonable (1sec or less). > Maybe that sysctl should be replaced with a generic one for > copy_file_range() > with a default of 64->128Mbytes. (I might make NFS use 1/2 of the sysctl > value, since the RPC response time shouldn't exceed 1sec.) > Does this sound reasonable? > > > And you think it's fine to allow copy_file_range on devfs, as long as > the len > > argument is clipped at some finite value. If we make all of those > changes, are > > there any other reasons why the write/read fallback path would be > needed? > I'm on the fence w.r.t. this one. I understand why you would prefer a call > that > worked for special files, but I also like the idea that it is "Linux > compatible". > Here's another datapoint: the iSCSI protocol includes server-side copies via the EXTENDED COPY command. And it looks like ctl(4) already supports that command. Wouldn't it be great if iscsi(4) also supported it? But it can't without a syscall like copy_file_range(2) to use it. > > I'd like to hear feedback from others on this. > Maybe I'll try asking this question separately on freebsd-current@ and > see if I can get others to respond. > > rick' > > -Alan > From owner-freebsd-hackers@freebsd.org Sat Sep 26 15:49:26 2020 Return-Path: Delivered-To: freebsd-hackers@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 8ECE642226D for ; Sat, 26 Sep 2020 15:49:26 +0000 (UTC) (envelope-from chris.stephan@live.com) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003104.outbound.protection.outlook.com [40.92.3.104]) (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 4BzCrj3MhDz3VKv; Sat, 26 Sep 2020 15:49:25 +0000 (UTC) (envelope-from chris.stephan@live.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XJl6jNJyP37bID1/6H4yRUchHJlSnqIH2fRMlKBzWuJF13tm2LuTlNZ6NnHT0VPtHlHVEfrz6926h/VdJ2zZzHtT9DUDPPrKpvXC1jOwrY/U8JPJyWk+naZqaLrFQ7Yk1bW4mx+QEH5tsIbNf74iA15MECxContrvA3WEkWF/k4DAJux+BGuQtrPVy4V9YlCLkmtXoC0C2zcO+6R8VAs69TDK5vON2JEI60m/UCESQGpQBQu8DCvrfYsfY96fxu0o6skx3q24M0MNJw4ZsEHH9FdhVOSpo61djlbSHi5ZdoEUGm7XrcOyNEJMWwfPAOHZEGE4hOqT4cN2x7gtO7JQg== 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=RNWG5Id3gZRCHJfAlqNFnsZLE4oaqDmYjKHqDxdWj14=; b=ax9zcqjcL3XoXKfTfvuYIc9R7uj8gOW1vsYFzWA/37QHlt4cWtoQMaJ4mb+SWfrjPIRlRDoynhtqswUm9BUhqKDV+2OdiJfe4EDXy1mg0P28xobk+3OOJUnLWCvSSFRt8HsaF4nFfUTitFeAjYW5efEER9CVKnSAkmrskHKam/hG50gZeuqlpmOz8ExCd5O68e/Z/dDuHE2UmfgpXQl584H7LkAjotojlxJeZMm27tLELcUHKNlnjitaJAJ0QDFgW18WTrXLlWc0Oxni4RZCsgQw/b0zv5JjMBRepuvUQMz2jjuWHW7DcH1IdXQSj2VkP5+9tSQjPEkXqseE8He4Vw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RNWG5Id3gZRCHJfAlqNFnsZLE4oaqDmYjKHqDxdWj14=; b=EL/4xdVdm8pWNoyhHZPzf+gi/dBIsS/uBt6t5Rh87prA9GcGjKhHc2o7nkGjpMpc1LazScQgSqc1GgehLmmJVxRGq8z3ZIZNz7de8+GCMMIx4kMhdjF+5CfD8m3FqJ7h2bi41stTuLvVELp/k+Vv1CRdhEpW9dpbbLh/FGTT1Wzi/J2c9inamt1+TIRnN394pwp0QaCnkrFpI2atb+H0Hd1ekidqmtB/nn0Wvau9UEfvb46kREnL+xWi3LuIEwB/I0Lv4RvLTBrCZlH7RH/nLrNlKw14tkJI08m3mxCvaTFBRLo2p+Kvof65LNLVx0Wlbt9I/zQJ70t1aFVCVJgNSA== Received: from CY1NAM02FT014.eop-nam02.prod.protection.outlook.com (10.152.74.56) by CY1NAM02HT112.eop-nam02.prod.protection.outlook.com (10.152.75.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Sat, 26 Sep 2020 15:49:24 +0000 Received: from SN6PR02MB5487.namprd02.prod.outlook.com (2a01:111:e400:7e45::41) by CY1NAM02FT014.mail.protection.outlook.com (2a01:111:e400:7e45::398) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Sat, 26 Sep 2020 15:49:24 +0000 Received: from SN6PR02MB5487.namprd02.prod.outlook.com ([fe80::d5a:e67f:4059:cae9]) by SN6PR02MB5487.namprd02.prod.outlook.com ([fe80::d5a:e67f:4059:cae9%6]) with mapi id 15.20.3391.027; Sat, 26 Sep 2020 15:49:24 +0000 From: Chris Stephan To: Rick Macklem , Alan Somers CC: FreeBSD Hackers Subject: Re: RFC: copy_file_range(3) Thread-Topic: RFC: copy_file_range(3) Thread-Index: AQHWj2Uifrs1HWO8TEG7tx3vFRkbjalxruGAgAABn4CAAHhpgIAAKJwAgAAu9oCACJnu2Q== Date: Sat, 26 Sep 2020 15:49:23 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:35534C1D4A077020E8EF01A0DED1DB04AFAEBC74A64A8783A2E8226546C52937; UpperCasedChecksum:0A64D3D7EFA964F54A7EE0CE21079698D0E984D523A76B56F95BB700C3DE76B3; SizeAsReceived:7322; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [pDmzpDXf977qndAhImgXzFU2EwLqQ2nZ] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 9c68f4e6-4bde-4ced-1cda-08d86233bdcc x-ms-traffictypediagnostic: CY1NAM02HT112: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3MskyCfAVCY01T2oYPxy7/6Qd25lYLBIR+QCFofSJcgR+jaUHrFT52Ue+7cKYbaoUIIJtVYakn+HFt9ZIXLc8TIhJbl5pj9HV033WEz/KV+KjCLuk023HPPuFm0/aikO1oY4weM5HfBTO5df0NJhuwA9/Y6nYo5ytRCa0hhYdZYA8eoM06DMii9rXlmfas0YDixrPIG7z9fU5+uKOfIjA5CsiamddbMo/PuMl+9tlDZBDIfFFdlPugxdseeeZcL1 x-ms-exchange-antispam-messagedata: inyZxfzZ900cgea4w1sFAX5OpRN6KOSud2xHIdkaGeSSKfaHIFyHnJaWToNQdxf4QCjWJpM/01WHuZBMd/Tg/ff2bXajg7oTwHJ4he5M+xUsKpDmHqRXk1nOl4LuUFOSijIaCAh1LafnaxFjZKJFTg== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: CY1NAM02FT014.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 9c68f4e6-4bde-4ced-1cda-08d86233bdcc X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2020 15:49:23.9080 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT112 X-Rspamd-Queue-Id: 4BzCrj3MhDz3VKv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=live.com header.s=selector1 header.b=EL/4xdVd; dmarc=pass (policy=none) header.from=live.com; spf=pass (mx1.freebsd.org: domain of chris.stephan@live.com designates 40.92.3.104 as permitted sender) smtp.mailfrom=chris.stephan@live.com X-Spamd-Result: default: False [-4.79 / 15.00]; DWL_DNSWL_NONE(0.00)[live.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[live.com:s=selector1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.3.104:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[live.com]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.004]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[live.com:+]; DMARC_POLICY_ALLOW(-0.50)[live.com,none]; RCVD_IN_DNSWL_NONE(0.00)[40.92.3.104:from]; NEURAL_HAM_SHORT(-0.79)[-0.793]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[live.com]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 15:49:26 -0000 New to the list and Late to the discussion. I am thinking increasing the Le= n could cause possible degradation of performance when used on slower or le= gacy systems. On the other hand just picking a len and cutting it off at a = hard max seems crude even with a tunable. Admittedly my naive opinion in th= is matter ponders, could there be a sysctl tunable that just sets an estima= te on timeframe instead of size. As you said 100M is roughly a sec on modem= hardware. IOPS are already tracked. The inverse of the avg IOPS for the fi= lesystem in question could be used against this tunable to derive the estim= ated size limit of the next read/write. This would allow the max len within= the syscall to both honor a timeframe before a signal would be handled and= maximize efficiency across a large breadth of systems varying in performan= ce. I=92m sure it is more complicated than I suggest... just tossing my 2c = in. Chris Sent from FreeBSD ________________________________ From: owner-freebsd-hackers@freebsd.org = on behalf of Rick Macklem Sent: Sunday, September 20, 2020 11:28:21 PM To: Alan Somers Cc: FreeBSD Hackers Subject: Re: RFC: copy_file_range(3) [I have only indented your most recent comments] Alan Somers wrote: On Sun, Sep 20, 2020 at 5:14 PM Rick Macklem > wrote: Alan Somers wrote: >On Sun, Sep 20, 2020 at 9:58 AM Rick Macklem >> wrote: >>Alan Somers wrote: >>>copy_file_range(2) is nifty, but it has a few sharp edges: >>>1) Certain file systems don't support it, necessitating a write/read bas= ed >>>fallback >>>2) It doesn't handle sparse files as well as SEEK_HOLE/SEEK_DATA >>>3) It's slightly tricky to both efficiently deal with holes and also >>>promptly respond to signals >>> >>>These problems aren't terribly hard, but it seems to me like most >>>applications that use copy_file_range would share the exact same >>>solutions. In particular, I'm thinking about cp(1), dd(1), and >>>install(8). Those three could benefit from sharing a userland wrapper t= hat >>>handles the above problems. >>> >>>Should we add such a wrapper to libc? If so, what should it be called, = and >>>should it be public or just private to /usr/src ? >>There has been a discussion on src-committers which I suggested should >>be taken to a public mailing list. >> >>The basic question is... >>Whether or not the copy_file_range(2) syscall should be compatible with >>the Linux one. >>When I did the syscall, I tried to make it Linux-compatible, arguing that >>Linux is now a de-facto standard. >>The Linux syscall only works on regular files, which is why Alan's patch = for >>cp required a "fallback to the old way" for VCHR files like /dev/null. >> >>He is considering a wrapper in libc to provide FreeBSD specific semantics= , >>which I have no problem with, so long as the naming and man page make >>it clear that it is not compatible with the Linux syscall. >>(Personally, I'd prefer a wrapper in libc to making the actual syscall no= n-Linux >> compatible, but that is just mho.) >> >>Hopefully this helps clarify what Alan is asking, rick >> >>I don't think the two questions are equivalent. I think that copy_file_r= ange(2) >>ought to work on character devices. Separately, even it does, I = think a userland >>wrapper would still be useful. It would still be able t= o handle sparse files more >>efficiently than the kernel-based vn_generic_c= opy_file_range. I saw this also stated in your #2 above, but wonder why you think a wrapper would handle holes more efficiently. vn_generic_copy_file_range() does look for holes via SEEK_DATA/SEEK_HOLE just like a wrapper would and retains them as far as possible. It also look= s for blocks of all zero bytes for file systems that do not support SEEK_DATA= / SEEK_HOLE (like NFS versions prior to 4.2) and creates holes for these in the output file. --> The only cases that I am aware of where the holes are not retained are: - When the min holesize for the output file is larger than that of the input file. - When the hole straddles the byte range specified for the syscall. (Or when the hole straddles two copy_file_range(2) syscalls, if you prefer.) If you are copying the entire file and do not care how long the syscall takes (which also implies how long it will take for a termination signal like C to be handled), the most efficient usage is to specify a "len" argument equal to UINT64_MAX. --> This will usually copy the whole file in one gulp, although it is not guaranteed to copy everything, given the Linux semantics definition of it (an NFSv4.2 server can simply choose to copy less, for example= ). --> This allows the kernel to use whatever block size works efficien= tly and does not require an allocation of a large userspace buffer= for the date, nor that the data be copied to/from userspace. The problem with doing the whole file in one gulp are: - A large file can take quite a while and any signal won't be processed unt= il the gulp is done. --> If you wrote a program that allocated a 100Gbyte buffer and then copied a file using read(2)/write(2) with a size of 100Gbytes in a = loop, you'd end up with the same result. - As kib@ noted, if the input file never reports EOF (as /dev/zero does), then the "one gulp" wouldn't end until storage is exhausted on the output file(s) device and C wouldn't stop it (since it is one b= ig syscall). --> As such, I suggested that, if the syscall is extended to allow VCH= R, that the "len" argument be clipped at "K Mbytes" for that case t= o avoid filling the storage device before being able to C ou= t of it, for this case. I suppose the answer for #3 is... - smaller "len" allows for quicker response to signals but - smaller "len" results in less efficient use of the syscall. Your patch for "cp" seemed fine, but used a small "len" and, as such, made the use of copy_file_range(2) less efficient. All I see the wrapper dong is handling the VCHR case (if the syscall remain= s as it is now and returns EINVAL to be compatible with Linux) and making some rather arbitrary choice w.r.t. how big "len" should be. --> Choosing an appropriate "len" might better be left to the specific use case, I think? In summary, it's mostly whether VCHR gets handled by the syscall or a wrapper? > 1) In order to quickly respond to a signal, a program must use a modest l= en with > copy_file_range Does this matter? Or put another way, is a 1-2sec delay in response to C an issue for "cp". When kib@ reviewed the syscall, he did not see the delay in signal handling a significant problem, noting that it is no different than a large process = core dumping. > 2) If a hole is larger than len, that will cause vn_generic_copy_file_ran= ge to > truncate the output file to the middle of the hole. Then, in the next in= vocation, > truncate it again to a larger size. > 3) The result is a file that is not as sparse as the original. > > For example, on UFS: > $ truncate -s 1g sparsefile > $ cp sparsefile sparsefile2 > $ du -sh sparsefile* > 96K sparsefile > 32M sparsefile2 If you care about maintaining sparseness, a "len" of 100Mbytes or more woul= d be a reasonable choice. Since "cp" has never maintained sparseness, I didn'= t suggest such a size when I reviewed your patch for "cp". --> I/O subsystem performance varies widely, but I think 100Mbytes will lim= it the delay in signal handling to about 1sec. Isn't that quick enough? > My idea for a userland wrapper would solve this problem by using > SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use copy_file_ra= nge for > everything else with a modest len. Alternatively, we could eliminate the= need for > the wrapper by enabling copy_file_range for every file system, and making > vn_generic_copy_file_range interruptible, so copy_file_range can be calle= d with > large len without penalizing signal handling performance. The problem with doing this is it largely defeats the purpose of copy_file_= range(). 1 - What about file systems that do not support SEEK_DATA/SEEK_HOLE. (All NFS mounts except NFSv4.2 ones against servers that support the NFSv4.2 Seek operation are in this category.) 2 - For NFSv4.2 with servers that support Seek, the copy of an entire file can be done via a few (or only one) RPC if you make "len" large and don't use Seek. If you combine using Seek with len =3D=3D2Mbytes, then you do a lot mo= re RPCs with associated overheads and RPC RTT delays. You still avoid moving a= ll the data across the wire, but you do lose a lot of the performance adv= antage. I could have made copy_file_range(2) a lot simpler if the generic code didn= 't try and maintain holes, but I wanted it to work well for file systems that = did not support SEEK_DATA/SEEK_HOLE. I'd suggest you try patching "cp" to use a 100Mbyte "len" for copy_file_ran= ge() and test that. You should fine the sparseness is mostly maintained and that you can = C out of a large file copy without undue delay. Then try it over NFS mounts (both v4.2 and v3) for the same large sparse fi= le. You can also code up a patched "cp" using SEEK_DATA/SEEK_HOLE and see how they compare. rick -Alan _______________________________________________ freebsd-hackers@freebsd.org mailing list https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flists.f= reebsd.org%2Fmailman%2Flistinfo%2Ffreebsd-hackers&data=3D02%7C01%7C%7C2= 7ea5166cf99415d3bba08d85de6d259%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%= 7C637362593231297450&sdata=3DSfm9MxjQ6MVHgG%2Fw3sghn0hebSFjZo%2FSaUyZ9H= Pyws8%3D&reserved=3D0 To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sat Sep 26 19:34:07 2020 Return-Path: Delivered-To: freebsd-hackers@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 840DF426F86 for ; Sat, 26 Sep 2020 19:34:07 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BzJqx53dxz40Lm for ; Sat, 26 Sep 2020 19:34:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 08QJXvk9077761 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 26 Sep 2020 12:33:57 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 08QJXvWp077760 for freebsd-hackers@freebsd.org; Sat, 26 Sep 2020 12:33:57 -0700 (PDT) (envelope-from sgk) Date: Sat, 26 Sep 2020 12:33:57 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: Informative dmesg logging? Message-ID: <20200926193357.GA77746@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4BzJqx53dxz40Lm X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [1.83 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.04)[0.039]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.15)[0.145]; NEURAL_SPAM_LONG(0.64)[0.643]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MAILMAN_DEST(0.00)[freebsd-hackers]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM, none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 19:34:07 -0000 Just updated to head including replacing drm-legacy-kmod with drm-current-kmod. During boot, I see these mesages: % dmesg | grep "local kernel" __pm_runtime_resume not implemented -- see your local kernel hacker pm_runtime_mark_last_busy not implemented -- see your local kernel hacker __pm_runtime_suspend not implemented -- see your local kernel hacker pm_runtime_get_if_in_use not implemented -- see your local kernel hacker __pm_runtime_resume not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker register_oom_notifier not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker kmem_cache_shrink not implemented -- see your local kernel hacker register_acpi_notifier not implemented -- see your local kernel hacker async_schedule is dodgy -- see your local kernel hacker pm_runtime_set_autosuspend_delay not implemented -- see your local kernel hacker __pm_runtime_use_autosuspend not implemented -- see your local kernel hacker async_synchronize_cookie not implemented -- see your local kernel hacker check_move_unevictable_pages not implemented -- see your local kernel hacker Other than filling dmesg output, is anyone interested in this info? -- Steve From owner-freebsd-hackers@freebsd.org Sat Sep 26 23:22:34 2020 Return-Path: Delivered-To: freebsd-hackers@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 5FEC23E3773 for ; Sat, 26 Sep 2020 23:22:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670079.outbound.protection.outlook.com [40.107.67.79]) (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 4BzPvX25Mnz4DRW; Sat, 26 Sep 2020 23:22:31 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RUhWE5UanoXCLnuWK83bTKfzbY6dj1yfoQmV6obPVYdNAJydaoZ5Hz5TdCF+BDfZqlufMQvd/ODYFWPPHwKs0/sNzqI54L6JeeJEJDNFZw0J7UwowM8ZKMSpmMof5gFFyzBITdepOvpgtjklLAyyidj9ULMNR3cDq8rdvrDGvTDLIZE5+2tg1ilDcUu91RiGIgoz6DXNbYxvvjTqotOEBftd2qJQCJxBvJhs35xDfd11GWV0YyK1AN8TyJ1KRgLuL/WrpAK4kHIwxLMizqDTaTeaZY/6ajtmcy3noFo/z4pU8/ZIx9fkbjKMSLvqbJrAPVEv9v1NxBCOyjBY6/0xEA== 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=eDWJu/FSehb01Hbv5jiPpEshpDZY+MqAj6fNkWb30/0=; b=Hw0JRLL9WbVawD8uA0UXX1v85l62ZitXxWwzjeh2RD2TWp2vt8S8+ocMuUR87SRM6ET6/9JFFaE1g4bGvNBTYwOBgKcmrZ9IaJzS1pD8JLABNfAYYX36r/5y6TwWlFCXiMdQRskKlU63A47MNT91HAhNKLrepqmVzGqE8MrRbNgRQl3LzAHqx7zG4+KgFUz+TCgPWoQ8aIQkSSKeqiLrzrzb7dfFW/Dd7YO0MhomjIW+Sr2QA5d6yX58jYki15d5r5fwYCzCFCM0DODPAqIQVFYCeZRHTkC6+15QgyekhY0y/cmvmkV/aJQz+7bXiJz+JuVkwLMn/cAYtz0GcmL90A== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eDWJu/FSehb01Hbv5jiPpEshpDZY+MqAj6fNkWb30/0=; b=SXMPKnc+YQaqP5lv+2goIjmirBnGzHPnTmxmaRAO185xYUsp54shNjneLD9nseITsNJkdOPPHwcnibr1TOSFUiSQhsVaSjdVByVm55hXamMKlYNDrL5Sjv9uHloh/bksyJKk423Rug6gpYf4Eh0QhDtFnroqGgdTXKAL8RtgXRf8nV+0kJr0qwkZodCHmGsng+LOrLYL+VwV7luwV7hAQNDr9PSS74VuclaSrAjZLo34mqcrb4DhRWSbGq+FrFL+b0W9OjeETX5SC5GFOwFgPr4CVVjkYgGW+dnCvOGuWIQkzf5goZdrLi93eKGoMHBou3LWigIwXweDe4BV/QhwqA== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YT1PR01MB3002.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:5::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.26; Sat, 26 Sep 2020 23:22:30 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3412.028; Sat, 26 Sep 2020 23:22:30 +0000 From: Rick Macklem To: Chris Stephan , Alan Somers CC: FreeBSD Hackers Subject: Re: RFC: copy_file_range(3) Thread-Topic: RFC: copy_file_range(3) Thread-Index: AQHWj2Uep8NVOqCTP0KuS7h/nlgLPqlxrARqgAAEfICAAHAflYAAMOYAgAApba+ACJ95gIAAfXJM Date: Sat, 26 Sep 2020 23:22:30 +0000 Message-ID: References: , , , In-Reply-To: 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: 0de80ecd-83b5-4e35-7baf-08d862730a43 x-ms-traffictypediagnostic: YT1PR01MB3002: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2582; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2t0Ju76wGdpSGto9RMbJBFp6bFrRyXPBeMcIRq/9KxfS1XDagYWIzWD9ts3SpnVJ6qZDIDpPEK+rcxlfcH4U4seHnDD6cuQIWmdv6eaPxizEUT8y3IH52WQ168CO5Yz4s6uQgXN36F/4RpaNbAPxC+9QKvUYqV/4CQMQhV3OCA4Q6DQHlbYdz3/EBINvsUrxDNIcE6SKaQMXu9FfTNw+PFggERvJbw0lfg5aAVX0V2NqQwGJDUMIwNxOggNmZEqAZH9TE3n2KmDMx/7sk/ozA+Asp3m5faXYTpVSLXlvcR1cqGbFps4XSU2aDGR8ITP9pkpcFfh7An6IKa90fV5OjQONqaYhBr3pdIYWPbwoMq35Pncl7AneR/O8sfappGlPRk51MdYBMyUcig1/uI3jbbMvXkg5AvFkg517CUu8vpjHIz1iE+eJ/wRvzYfM75eWJIis6F87Ks38jj6AyDhY3Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(366004)(346002)(136003)(376002)(39850400004)(966005)(110136005)(45080400002)(4326008)(7696005)(5660300002)(64756008)(55016002)(66556008)(316002)(186003)(6506007)(83380400001)(66476007)(9686003)(66446008)(53546011)(2906002)(786003)(8676002)(33656002)(86362001)(76116006)(91956017)(66946007)(52536014)(478600001)(8936002)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: alko2blpZmH9wahUGdsKUQrLsajQ/ettvdzVht9CAsClzw4rPYwGIaKFSOvLDFk3ofFDwMzeM2S/J/JQpVmZXwZIGsm7JKJGm1Mr55gENNoBtL3hOPPElmJsUG/JoBTO0dmS64/OhpMz1xM0sbTFpoFRBR7rgnrR9yZCD7h4JXz9Bojso4KozHoNQEnC5sv//xs8oo9uy+wr/WRJ2ANenANrbA/dwS+hIzdFV6ZwtYUvhp2/7tiNRfxmchpA9010DxqMTsoAt4pEY8v48iDxhDu3Ab8XGb10ZYk4TnVR9cPwKjYOrPhmjOffb3Vv2TgGpSSmuqN9BCpc2cSjKP08g6/EA184nv5Uxoiz+TRieJ8DDswSN0Cf+D/TojOdP8e5L4I8t6XPNLJ+7spKdg0Iip+MCKkp3FcOHNjSZvK6+AQ9ZKusLRUm6Cet8MmnPHHXKQ6vM5pu4tuOvnbS9HutGdS5TwaLKO1Kz/uGJANbRIka/8s537QR5CltuJWwXvznzXj8O9SMRhGCSMBENcfKmPyczF4CnWxJJkJw9RlzqGiy+nB5+LJy8gHRAxp0Inelg085xXbKMcD4E5LJXhjGPLOTZWFJ4IpiIPgCB2IBVQW40jOrY7l3N884DhU3XLeOCMVSnlC1yrH8d6A8WoWyd1q9sqhGhsaTqOU+AHFatEMnvZrMDSRsvsqOe5ifQygNp4BffAkcql0hfPT9dME2hg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 0de80ecd-83b5-4e35-7baf-08d862730a43 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2020 23:22:30.5151 (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: lUFUkM+KiYJyGUcsdSF2J+JHaNVW6fpkrfffqiHms867226/8ySHBD+Lf59LT29nJkk6IsqgsaM6vvUbFZSN+g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB3002 X-Rspamd-Queue-Id: 4BzPvX25Mnz4DRW X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=SXMPKnc+; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.79 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.01 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-0.99)[-0.991]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.79:from]; NEURAL_HAM_SHORT(-1.02)[-1.021]; FREEMAIL_TO(0.00)[live.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.79:from] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 23:22:34 -0000 Chris Stephan wrote:=0A= > New to the list and Late to the discussion. I am thinking increasing the = Len could=0A= > cause possible degradation of performance when used on slower or legacy = =0A= > systems. On the other hand just picking a len and cutting it off at a har= d max =0A= > seems crude even with a tunable. Admittedly my naive opinion in this matt= er =0A= > ponders, could there be a sysctl tunable that just sets an estimate on ti= meframe =0A= > instead of size. As you said 100M is roughly a sec on modem hardware. IOP= S are=0A= > already tracked. The inverse of the avg IOPS for the filesystem in questi= on could =0A= > be used against this tunable to derive the estimated size limit of the ne= xt =0A= > read/write. This would allow the max len within the syscall to both honor= a =0A= > timeframe before a signal would be handled and maximize efficiency across= a=0A= > large breadth of systems varying in performance. I=92m sure it is more co= mplicated =0A= > than I suggest... just tossing my 2c in.=0A= Yes. Using time will work for the generic copy case and I think that's a go= od idea.=0A= Then we can leave the file system specific cases up to the implementors.=0A= (For NFSv4.2, once you send the RPC to the server, the client has no contro= l over=0A= how long it takes to reply. The current sysctl that sets a size is still a= bout all the=0A= NFSv4.2 code can do.)=0A= =0A= Thanks for the suggestion, rick=0A= =0A= Chris=0A= =0A= Sent from FreeBSD=0A= ________________________________=0A= From: owner-freebsd-hackers@freebsd.org = on behalf of Rick Macklem =0A= Sent: Sunday, September 20, 2020 11:28:21 PM=0A= To: Alan Somers =0A= Cc: FreeBSD Hackers =0A= Subject: Re: RFC: copy_file_range(3)=0A= =0A= [I have only indented your most recent comments]=0A= Alan Somers wrote:=0A= On Sun, Sep 20, 2020 at 5:14 PM Rick Macklem > wrote:=0A= Alan Somers wrote:=0A= >On Sun, Sep 20, 2020 at 9:58 AM Rick Macklem >> wrote:=0A= >>Alan Somers wrote:=0A= >>>copy_file_range(2) is nifty, but it has a few sharp edges:=0A= >>>1) Certain file systems don't support it, necessitating a write/read bas= ed=0A= >>>fallback=0A= >>>2) It doesn't handle sparse files as well as SEEK_HOLE/SEEK_DATA=0A= >>>3) It's slightly tricky to both efficiently deal with holes and also=0A= >>>promptly respond to signals=0A= >>>=0A= >>>These problems aren't terribly hard, but it seems to me like most=0A= >>>applications that use copy_file_range would share the exact same=0A= >>>solutions. In particular, I'm thinking about cp(1), dd(1), and=0A= >>>install(8). Those three could benefit from sharing a userland wrapper t= hat=0A= >>>handles the above problems.=0A= >>>=0A= >>>Should we add such a wrapper to libc? If so, what should it be called, = and=0A= >>>should it be public or just private to /usr/src ?=0A= >>There has been a discussion on src-committers which I suggested should=0A= >>be taken to a public mailing list.=0A= >>=0A= >>The basic question is...=0A= >>Whether or not the copy_file_range(2) syscall should be compatible with= =0A= >>the Linux one.=0A= >>When I did the syscall, I tried to make it Linux-compatible, arguing that= =0A= >>Linux is now a de-facto standard.=0A= >>The Linux syscall only works on regular files, which is why Alan's patch = for=0A= >>cp required a "fallback to the old way" for VCHR files like /dev/null.=0A= >>=0A= >>He is considering a wrapper in libc to provide FreeBSD specific semantics= ,=0A= >>which I have no problem with, so long as the naming and man page make=0A= >>it clear that it is not compatible with the Linux syscall.=0A= >>(Personally, I'd prefer a wrapper in libc to making the actual syscall no= n-Linux=0A= >> compatible, but that is just mho.)=0A= >>=0A= >>Hopefully this helps clarify what Alan is asking, rick=0A= >>=0A= >>I don't think the two questions are equivalent. I think that copy_file_r= ange(2) >>ought to work on character devices. Separately, even it does, I = think a userland >>wrapper would still be useful. It would still be able t= o handle sparse files more >>efficiently than the kernel-based vn_generic_c= opy_file_range.=0A= I saw this also stated in your #2 above, but wonder why you think a wrapper= =0A= would handle holes more efficiently.=0A= vn_generic_copy_file_range() does look for holes via SEEK_DATA/SEEK_HOLE=0A= just like a wrapper would and retains them as far as possible. It also look= s=0A= for blocks of all zero bytes for file systems that do not support SEEK_DATA= /=0A= SEEK_HOLE (like NFS versions prior to 4.2) and creates holes for these in= =0A= the output file.=0A= --> The only cases that I am aware of where the holes are not retained are:= =0A= - When the min holesize for the output file is larger than that of the= =0A= input file.=0A= - When the hole straddles the byte range specified for the syscall.=0A= (Or when the hole straddles two copy_file_range(2) syscalls, if you= =0A= prefer.)=0A= =0A= If you are copying the entire file and do not care how long the syscall=0A= takes (which also implies how long it will take for a termination signal=0A= like C to be handled), the most efficient usage is to specify=0A= a "len" argument equal to UINT64_MAX.=0A= --> This will usually copy the whole file in one gulp, although it is not= =0A= guaranteed to copy everything, given the Linux semantics definition= =0A= of it (an NFSv4.2 server can simply choose to copy less, for example= ).=0A= --> This allows the kernel to use whatever block size works efficien= tly=0A= and does not require an allocation of a large userspace buffer= for=0A= the date, nor that the data be copied to/from userspace.=0A= =0A= The problem with doing the whole file in one gulp are:=0A= - A large file can take quite a while and any signal won't be processed unt= il=0A= the gulp is done.=0A= --> If you wrote a program that allocated a 100Gbyte buffer and then=0A= copied a file using read(2)/write(2) with a size of 100Gbytes in a = loop,=0A= you'd end up with the same result.=0A= - As kib@ noted, if the input file never reports EOF (as /dev/zero does),= =0A= then the "one gulp" wouldn't end until storage is exhausted on the=0A= output file(s) device and C wouldn't stop it (since it is one b= ig=0A= syscall).=0A= --> As such, I suggested that, if the syscall is extended to allow VCH= R,=0A= that the "len" argument be clipped at "K Mbytes" for that case t= o=0A= avoid filling the storage device before being able to C ou= t=0A= of it, for this case.=0A= I suppose the answer for #3 is...=0A= - smaller "len" allows for quicker response to signals=0A= but=0A= - smaller "len" results in less efficient use of the syscall.=0A= =0A= Your patch for "cp" seemed fine, but used a small "len" and, as such,=0A= made the use of copy_file_range(2) less efficient.=0A= =0A= All I see the wrapper dong is handling the VCHR case (if the syscall remain= s=0A= as it is now and returns EINVAL to be compatible with Linux) and making=0A= some rather arbitrary choice w.r.t. how big "len" should be.=0A= --> Choosing an appropriate "len" might better be left to the specific use= =0A= case, I think?=0A= =0A= In summary, it's mostly whether VCHR gets handled by the syscall or a=0A= wrapper?=0A= =0A= > 1) In order to quickly respond to a signal, a program must use a modest l= en with > copy_file_range=0A= Does this matter? Or put another way, is a 1-2sec delay in response to C=0A= an issue for "cp".=0A= When kib@ reviewed the syscall, he did not see the delay in signal handling= =0A= a significant problem, noting that it is no different than a large process = core=0A= dumping.=0A= =0A= > 2) If a hole is larger than len, that will cause vn_generic_copy_file_ran= ge to=0A= > truncate the output file to the middle of the hole. Then, in the next in= vocation,=0A= > truncate it again to a larger size.=0A= > 3) The result is a file that is not as sparse as the original.=0A= >=0A= > For example, on UFS:=0A= > $ truncate -s 1g sparsefile=0A= > $ cp sparsefile sparsefile2=0A= > $ du -sh sparsefile*=0A= > 96K sparsefile=0A= > 32M sparsefile2=0A= If you care about maintaining sparseness, a "len" of 100Mbytes or more woul= d=0A= be a reasonable choice. Since "cp" has never maintained sparseness, I didn'= t=0A= suggest such a size when I reviewed your patch for "cp".=0A= --> I/O subsystem performance varies widely, but I think 100Mbytes will lim= it=0A= the delay in signal handling to about 1sec. Isn't that quick enough?= =0A= =0A= > My idea for a userland wrapper would solve this problem by using=0A= > SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use copy_file_ra= nge for=0A= > everything else with a modest len. Alternatively, we could eliminate the= need for=0A= > the wrapper by enabling copy_file_range for every file system, and making= =0A= > vn_generic_copy_file_range interruptible, so copy_file_range can be calle= d with=0A= > large len without penalizing signal handling performance.=0A= The problem with doing this is it largely defeats the purpose of copy_file_= range().=0A= 1 - What about file systems that do not support SEEK_DATA/SEEK_HOLE.=0A= (All NFS mounts except NFSv4.2 ones against servers that support the= =0A= NFSv4.2 Seek operation are in this category.)=0A= 2 - For NFSv4.2 with servers that support Seek, the copy of an entire file= =0A= can be done via a few (or only one) RPC if you make "len" large and=0A= don't use Seek.=0A= If you combine using Seek with len =3D=3D2Mbytes, then you do a lot mo= re RPCs=0A= with associated overheads and RPC RTT delays. You still avoid moving a= ll=0A= the data across the wire, but you do lose a lot of the performance adv= antage.=0A= =0A= I could have made copy_file_range(2) a lot simpler if the generic code didn= 't=0A= try and maintain holes, but I wanted it to work well for file systems that = did=0A= not support SEEK_DATA/SEEK_HOLE.=0A= =0A= I'd suggest you try patching "cp" to use a 100Mbyte "len" for copy_file_ran= ge()=0A= and test that.=0A= You should fine the sparseness is mostly maintained and that you can = C=0A= out of a large file copy without undue delay.=0A= Then try it over NFS mounts (both v4.2 and v3) for the same large sparse fi= le.=0A= =0A= You can also code up a patched "cp" using SEEK_DATA/SEEK_HOLE and see=0A= how they compare.=0A= =0A= rick=0A= =0A= =0A= -Alan=0A= _______________________________________________=0A= freebsd-hackers@freebsd.org mailing list=0A= https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flists.f= reebsd.org%2Fmailman%2Flistinfo%2Ffreebsd-hackers&data=3D02%7C01%7C%7C2= 7ea5166cf99415d3bba08d85de6d259%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%= 7C637362593231297450&sdata=3DSfm9MxjQ6MVHgG%2Fw3sghn0hebSFjZo%2FSaUyZ9H= Pyws8%3D&reserved=3D0=0A= To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= =0A= From owner-freebsd-hackers@freebsd.org Sat Sep 26 23:33:47 2020 Return-Path: Delivered-To: freebsd-hackers@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 C6BF33E3F5E; Sat, 26 Sep 2020 23:33:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670086.outbound.protection.outlook.com [40.107.67.86]) (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 4BzQ8V68DDz4FFF; Sat, 26 Sep 2020 23:33:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ddVtrY+rCYXKQJylVPjHbH1oItpO8Ia5BlIkmUVE2CKx6mbPIFqdst6UKUGIZHQ+5f/KLkhIr1Eq5UVIjFGbbfI+Z2mrO8TnFMXA6vwM3YbNZelbnAmKO+2gwgSEroyLXLIPd1VKEsACS18Sq2Z4fcOAxmqmnTq6lAzlg7ue6nJcXVpq2eseKlJCchUFuVm3bsOc2rdAgMDSnQ/X1MwcLWlPYfuoCN4p1u1j0VZXmZSTuZYBUTzk6vpensfxEFl/UBLj2aSBa7dWMp7z1GtTXnTZ4qLAS0kD3FDgutWqXL985Ls3BA6bdF+qoI0VBv42+tSflBKyBS0Hqxa+eOoumQ== 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=+Rkkv0hXCDZGCy6t5EEvQOUpgw8GuR9sF9agdctGgI4=; b=hGnaOeljvxPM32V1B6J17cDDQssCfx60Ti8bqwlrMqy1tYOtD4xJJqCR3vHvuUFXrs+nATO1nEBCd95DUEvUd1WlRfQAOFGml/Hkhy6E2C3ttezAX02PU8r5J2DSiv4KvB6ORLnVtiICf+NE/LRdyEc5ve3VtpuVQJqx06+nYxOH41MsNEwlRsa3mhZr+bj7DDz+MtQnSmIIUDMDx3eYtszk5TeuMRiWmN1E8s1202DDWSbaMQhJn7sO4bQ9RdOYGOSIGYESU+NdiH8aVL8PaXq+1YT59ogXPr/JroqePYJavxX+gPP8F1Av7a7qNknf19pYLkJXpA49ibl83v+XfQ== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+Rkkv0hXCDZGCy6t5EEvQOUpgw8GuR9sF9agdctGgI4=; b=Ne+2Qxxi7kW+8ZBQhfjWRF5bEQrLtnPpo0Lq0lZJZYRuK9Aupyw3y3dqnAZS0UVXMaIsTuzJRkAjyZNt+hU6xSxNXuuBFCGT+shko/jaXfP8tEntUIW+Vy2UEOnx9XmDGZXkv8thzpXY//l4MfnCfniPFRrqjkzMSDMpI+68XuYxjb6Gz9O6I5N1LwcKcsphR8vtM5cBmXS/LmRzU3zLgBsHVdnG2FMbYOEviuZxYh7JYezaE3ZTAE+xcSDmqBMSkTIfg+DNiJdAYq+tRy1nnjFagAl3ES2PFEtAi2ZUQN2W4r3jQTzP4uyCupfuMIADOTFjxwepISgDqhf7xSHRow== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTBPR01MB3438.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:1b::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.26; Sat, 26 Sep 2020 23:33:45 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3412.028; Sat, 26 Sep 2020 23:33:45 +0000 From: Rick Macklem To: FreeBSD Hackers , "freebsd-current@freebsd.org" Subject: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Topic: RFC: should copy_file_range(2) remain Linux compatible or support special files? Thread-Index: AQHWlFwtm/+ImGEdKkCaptKgpElFKw== Date: Sat, 26 Sep 2020 23:33:45 +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: a57845c6-fc79-4463-a624-08d862749c5f x-ms-traffictypediagnostic: YTBPR01MB3438: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sduuz81oYZB7ti09m+skZyFjS40Zd9pzmUggqzDQpNxh/vTEJN0edI7uUh8ApxGoZmJiKnspqfYHcG87QA6tIP2P7eVzCB2EsRSvqwe9RAyG68fpn6cyeIkDIfiP79gCkrXwWWDpAFUTbkvJiHmOh4+yq/XE7G5kKfE8ijRPiFwTsxTh+8YCcK/QmSuYgwFFkoSNV7wAKFttB4OSyHXuEC0JPE3YkOB3h6LayhxR13aSk7QjRpJhXAZ+E7xVnI+iB6gvQSt8w0gsinA0mtXUYK56EQfUNLeWYEwdjYxilGnYAJwD4RWd4UsG6acR5kUZQi5FIvivur4hFlscd0NNbPIYM1wuMkp5NtLuqwAkt1JBk4KtgB66fLH7/0zHfvr2 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(396003)(366004)(346002)(136003)(39850400004)(8936002)(110136005)(8676002)(316002)(786003)(450100002)(86362001)(6506007)(7696005)(186003)(478600001)(55016002)(9686003)(2906002)(66446008)(64756008)(66556008)(66476007)(5660300002)(52536014)(83380400001)(33656002)(91956017)(66946007)(71200400001)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PDpvw9Tefe9g8ktGphXSmoMrGtwnL+QTW9cygeFa++6TUHKSrtkwUo6am/WxAyUJU48f4bBgrvDV9Fxyh11uYsB1Isb5FRWvXXleE9mRBi5LMfMngnsDSgIO126BCT6k/CzivZdwWDJtk/xP92ukhcFVX6r7vSwx2IBVpzCF9L1OIyFZ6o0+GXMq9tP04RjQxwAi/2EhpkhO+IPwuRmxa5DDQrLI7OcRn4DAZBNqxsJ0nksol18V/n8runpSTHkkslDAK3YHuEzegnBvluNwH4wWUS89jtWXerYG9b95Tu8Z7gdETKBLFRzU3Hkefz91KWVjK1aCnxfiYdKL93huuKHFSs1Ou0WfBeRtFdLOrJEdATlWN2yCEaNzkVJzhgYTkaoZbtNW/k43PO0c493zH+C/rSULsS4Q28jAx7HN7EZL+n1czTXoeo4Khb65s62WRLag8T0frdrYboy1/JM63zoBjfKkKPF9ROcn6L/VaoWTUFzZG1y1N2Rh0NiWqff5QK1mcMtgXDd8CGHgYjnGa63jVFZvbR0m6F+UjvXYU5gbeC8I/o/QlLuf3dnLppssDAXE1y9Z0+zGIoiZ97C2ZsjPBv53fQT9QUY6akQWHuaUQCGjL8R1T/Y8nCesHeSGkzwiLkxkTzNkYmr0xwmRDQTsJUb2VWQSEOPWX6F//fiXwXZNESbPR5OWmF2SJSeu+ZsNP9y7LqyfN4pJcZVRew== x-ms-exchange-transport-forked: True 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a57845c6-fc79-4463-a624-08d862749c5f X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2020 23:33:45.1618 (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: qCanHT8AAeqYRPkoCpmMcU9te9GzSzAq8kn4CS74ExJy64BqGL4CDyHPJgBy/eggDx30zwroumAMjKJ6ExnhxQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3438 X-Rspamd-Queue-Id: 4BzQ8V68DDz4FFF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=Ne+2Qxxi; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.86 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.73 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.01)[-1.009]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.86:from]; NEURAL_HAM_SHORT(-0.73)[-0.729]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.86:from] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 23:33:47 -0000 I know cross-posting is frowned upon, but I wanted everyone who might=0A= like to comment to see this.=0A= =0A= Currently copy_file_range(2) only supports regular files, which is compatib= le=0A= with the Linux one, where EINVAL is returned when either file descriptor=0A= refers to a non-regular file.=0A= =0A= Alan Somers would like to extend the syscall to handle special files.=0A= I think he has a couple of reasons for this (he can correct me):=0A= - When integrating it into "cp", he needed to provide a fallback for=0A= special files and similar fallbacks would probably be needed for=0A= other utilities like "dd".=0A= - iSCSI provides a "copy" operation which could be implemented using=0A= copy_file_range(2)/VOP_COPY_FILE_RANGE() if it supported special files.= =0A= =0A= kib@ was concerned that a copy from /dev/zero would fill a disk, but=0A= I think that issue can be dealt with by limiting the duration of the syscal= l=0A= to 1sec (so that the utility can be terminated via SIGTERM or similar).=0A= =0A= I am on the fence w.r.t. since I modelled it after the Linux one and keepin= g=0A= it Linux compatible would facilitate portable code, but I understand why=0A= Alan Somers wants to extend it (the iSCSI support seems particularily usefu= l).=0A= =0A= Everyone, please comment on this, rick=0A=