From nobody Wed Oct 4 13:31:15 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S0wZH2pMPz4vwbr for ; Wed, 4 Oct 2023 13:31:19 +0000 (UTC) (envelope-from troy.denton@mail.utoronto.ca) Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2139.outbound.protection.outlook.com [40.107.115.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S0wZG4S9bz3W83; Wed, 4 Oct 2023 13:31:18 +0000 (UTC) (envelope-from troy.denton@mail.utoronto.ca) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mail.utoronto.ca header.s=selector1 header.b=lWP6O3tJ; spf=pass (mx1.freebsd.org: domain of troy.denton@mail.utoronto.ca designates 40.107.115.139 as permitted sender) smtp.mailfrom=troy.denton@mail.utoronto.ca; dmarc=pass (policy=none) header.from=utoronto.ca; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TAj7BvNKtHiOPx+BYN/vaEGtWekTjqFveuPaOLjZEQUNsh9sQPTK/W7IKOy9ffzYNn+GDCTspB1ccpyVO4XSQ8BHQsOM3pgpZ6373Zj6UUKXGvIfJvUomVABPfgjOhk5I15RDJivVKrHFo4hXspvvYpTovwXcyNOt6TBx7fK4ZCRwPevZihm2cBZlqAmlMytxcgKe+OfRIKcQ/kJwvS8SOVuwv5GINaXcSkqr4hcVOr5yvwOfbaW9oab19F+5OxXFG2ixbjwQjkytWmQOgs60xKGjje2oJXbMOlDIqKIf2B9bM2B0H9ZzA1J6ghx/E9x7DXUcK8dOAaY2s8wCzh6Zg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hpYRonJ4/r2v4h++BDo5cW2WxiOAHgFIzyOhHcyNsVk=; b=DeUfTyiFhugGU9QPrFBuq4nTHKjYA0iTE9GzGr/bGMVruygg2IgxC7JJ+s9YbAJpaf6l/KJgHrSd1fXi8iwqRxtn/hEwLAEPZSvCb4nvoapZVQdxF9TJjeS7yiFCD36a4Bdz/UylUfhXohWdhAh+lIoqW9a3MjKJ1fcsn9XcmBow6cZEliJ8VewCZi0Kx4h9MA6CdLilFvrla0Iero/DQXMeg2ZP7LprGcJLhEDFdFp7BGiFv2lPWZA8wU41mCO9Kewl96vbQTC20Rq9Fs6HVMF1vTq+Iv0gppWwwYZUcgTmPzIwvsEZ9Mz+f2/1s9vvWus/T8kBizzl3Ccg9nXFlg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mail.utoronto.ca; dmarc=pass action=none header.from=mail.utoronto.ca; dkim=pass header.d=mail.utoronto.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.utoronto.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hpYRonJ4/r2v4h++BDo5cW2WxiOAHgFIzyOhHcyNsVk=; b=lWP6O3tJCS2lYmg+rj6iwh0de3IOGJlda+LSX9mEMy/uFAxSeaxfjOLKPbx48I4LFgiutWMsIxNixpDNnvmXIoAcRGIcAoMtYs1QT07kGvHW+2sSduYmSy0gv2RV3BgH2w3VHghSAOAvQ2VQXVKotk/4H7V0IipfwyGuFoD2CCU= Received: from YQXPR01MB4168.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:10::16) by YQBPR0101MB8606.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:55::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.34; Wed, 4 Oct 2023 13:31:15 +0000 Received: from YQXPR01MB4168.CANPRD01.PROD.OUTLOOK.COM ([fe80::2e78:bb9e:7d47:362e]) by YQXPR01MB4168.CANPRD01.PROD.OUTLOOK.COM ([fe80::2e78:bb9e:7d47:362e%6]) with mapi id 15.20.6838.033; Wed, 4 Oct 2023 13:31:15 +0000 From: Troy Denton To: "freebsd-hackers@freebsd.org" CC: "schweikh@FreeBSD.org" Subject: Project Ideas/POSIX Compliance Testing - Grad school project Thread-Topic: Project Ideas/POSIX Compliance Testing - Grad school project Thread-Index: AQHZ9sOobqdJ9yC7jkSX9KR9QrgETg== Date: Wed, 4 Oct 2023 13:31:15 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: YQXPR01MB4168:EE_|YQBPR0101MB8606:EE_ x-ms-office365-filtering-correlation-id: 486ad8bf-766f-423b-ccc9-08dbc4de2f4e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1DrEeHqdsrMOXs9Rtn72S6nKYYX+0zzW2wMS4EGZ7kbgFueSELibhP3dMKRwspaXAmWBRHhv92dWGE6jVdtqF0GSXcudZdtS/kCxvZ9equUAjFenW/SqLoT6hBm6+YUVyMrHKhXBHF7f039BDa75dqTRRbTjtsK3e6C0IDS5I1G+lpnURyPt4eLXDteKxjur+gTuGKQK+iYZKbmSlIdt+T7TuZOhCUOnemwK9dDrV46LFNN3Bz5VsN8aQBveoKqwpT7PMo3jnUnUPzhkjr/nLmbCQETJbUOEDqS+gUYaqkt1e0b3T4I0IK4indzjU6xqjUfGOGNXbcW7uwU3tyQlVLopTT1zTjpXNmXB5iYhuJPwfAvnastJNcVBmNtTwt2p6Xt+T/o/X2lYkNmET2EPhynfklMqjxDL9o2ZNXbiZOHXKD1lS5rfjEcXaIZReX5kwfoXGIrW3OqdUBT/+PHyX/3LSkVoFx8JX2n2dAYVfuW8QyH/W8r7/PgyJITj2+3iWfAOIjC/anYHq/2nNketTnixVwDzlNrFTpZ5FRzuqz3Df/iE3qjafMCJdh+yGwTuBQJyAunXV4gfg2OfaqGIxA2PWVQKWLmpjvsTcl9b/+Y= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR01MB4168.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230031)(136003)(396003)(39860400002)(366004)(376002)(346002)(230922051799003)(186009)(1800799009)(451199024)(64100799003)(6506007)(71200400001)(7696005)(478600001)(966005)(9686003)(26005)(91956017)(2906002)(41300700001)(4744005)(66946007)(76116006)(786003)(6916009)(44832011)(64756008)(5660300002)(66556008)(450100002)(52536014)(8676002)(316002)(8936002)(4326008)(33656002)(66476007)(66446008)(86362001)(38070700005)(38100700002)(122000001)(166002)(66899024)(55016003)(19627405001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?HE2T5BS0UrokjIfB9OYwIpzsf2r4izM404pq8Fwhna1R6PMtEftODSadCQ?= =?iso-8859-1?Q?jaddvUgg6f0soAcpZUEbmxFMX85nBA4b5L+9kfWJLJKC/r8Yk7cVQOMd6u?= =?iso-8859-1?Q?c/g6+txpm4WIM7Zx2WV/kpBnIC4pqsxLCM0ANvTIsqpfYkbHr5PzO/Poo4?= =?iso-8859-1?Q?MAfZ8tWGKtuu52smFEXDLmOyDkcGiWrrIbEbgwyDjbrnuh9V/JK/hB5ITH?= =?iso-8859-1?Q?3wBV29D31zn+jGioIbDJIZZroVwxRAiD7tVFrFm//lnNBbsZ6bGNp5nhX7?= =?iso-8859-1?Q?RAD85mdG+i9ofotsmxfMTy/aS0TTtK2DWKfalhg+/ncqsi4c+YxjEPBXyL?= =?iso-8859-1?Q?wtQ6CCGn1ZR9ZLGX6HgspiEcx9GfJha2U6Ak+Uhm04rXidjoM4uhsH5H0M?= =?iso-8859-1?Q?LY4g9MxWG0iUYysqS2ocsJ9j1Qog8ojS5bNGn0Ish4rW/jhdHFFDcW1cfY?= =?iso-8859-1?Q?+74ydNI7ArwzF30VIp4zYS3+Jep3hkHlJ1ZKy485izu0et6PgB00Q+UxAt?= =?iso-8859-1?Q?A1sQzS6rcgvdU2HDpRC7lZf+Rbq83c1Dl5I+nTfwnxqISZw2KSGrss5Ydv?= =?iso-8859-1?Q?cxeeX7tS7dc3xp6vVoQYEKakPO/VLS0gngVwtxnadZU1Vg5pR2Dw4LIlPk?= =?iso-8859-1?Q?LztjqnI3+4uAeQ1vrbRtgBESXkZxINzR6GaCX8UGh/NYg/90z/ujmCI2y3?= =?iso-8859-1?Q?X7TAo+2HFp59R2SU/bd99ypOCf9zB1GnwHZm7tkCP885QYENTIBIc3HvyO?= =?iso-8859-1?Q?2IlC165/Cn85vzFGOaoUN9h7gVxIrg1G/G/3wbZtIryv9JHZ76Gw8a238y?= =?iso-8859-1?Q?VIv9Ee/oIgjTukG/xpXhGgbSx9u4zeX/8FS+nmr+YAVJNn38SjD9L0293s?= =?iso-8859-1?Q?6FSHlIySkyX+cBS01dbWRIeGAjkdVHf789a2V8+5RlsrXR3Dx3/HcZynEp?= =?iso-8859-1?Q?SoXpE7fLruxxdTkS1g5e22WYXfHRDBTS7Y92jSqKzONB95PwKRPZU/uihm?= =?iso-8859-1?Q?ldoTvqrlbjPQVceHVHY3Q/pFBfqz94g4Hg4VlZ/gehgTtFxqbEohLpNVdn?= =?iso-8859-1?Q?fx2PXG00oHmLZbGouWq2NUfqs6RaO046Eyk4s6XUmsjUtu1RUdZPuyKgGI?= =?iso-8859-1?Q?Qf7lZQ6NpJty6uGnrFFwcdI3PxgwN9dwxSZoEaxi4LV1n2sxz5+/XtxktT?= =?iso-8859-1?Q?DkrY2/aTw5z1jF2anaaYwLEQN5XTsZouN4WZErCXoAkQ5OQCoPVTxsazhe?= =?iso-8859-1?Q?2XFPnKtWbS0hw4VcrTZbaIgAMum1oCcYpadKfRsN6j/2USiJycq9HAZrAn?= =?iso-8859-1?Q?va9pZisuAKtwIjpYNBnl0noi2/qTN+dqUq2YehjPPBlvd4jnd3bmB98t9/?= =?iso-8859-1?Q?Eo8r+EIbv2xRrgMZ173wcPz9APvVoWOvWWk3v4kTIl87CNk4TtJhFuEE/e?= =?iso-8859-1?Q?S4giI1l5ACyvj99R29H2QMzb3eaJpGz4l8x9iPDPA03t5CP9hfNgT6NaMR?= =?iso-8859-1?Q?NkMpCsds6bpLFPGFet7EYHapC4mOaoCs8+n9z2yzJ/5gCmAi8M5H/6K7/T?= =?iso-8859-1?Q?f8FEqYM7BDKrY188h3LnmxpDHqnHiHNfBMJleV/rU6Hiw7+sD4jEodxz1X?= =?iso-8859-1?Q?HU+Z3slTgwZO5+ssrsCJTDKHl7WSHaew6N?= Content-Type: multipart/alternative; boundary="_000_YQXPR01MB41685289EB353E39D8023839D3CBAYQXPR01MB4168CANP_" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: mail.utoronto.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR01MB4168.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 486ad8bf-766f-423b-ccc9-08dbc4de2f4e X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2023 13:31:15.8522 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 78aac226-2f03-4b4d-9037-b46d56c55210 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +w2h4eFMh/PeYY5X4NG3hPbMbA5WzZObhakU41fd0i9CvaRhCuDr4ag8w5dt/096YovVhzE+njknvGGXrY7l+Cm/VAGwQW9027rfaFLYAd0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB8606 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[utoronto.ca:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[utoronto.ca,none]; R_DKIM_ALLOW(-0.20)[mail.utoronto.ca:s=selector1]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.115.139:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[mail.utoronto.ca:+]; RCVD_IN_DNSWL_NONE(0.00)[40.107.115.139:from]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4S0wZG4S9bz3W83 --_000_YQXPR01MB41685289EB353E39D8023839D3CBAYQXPR01MB4168CANP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello list, I need a term project for a grad school OS course, and the "POSIX Complianc= e Testing" project listed at https://wiki.freebsd.org/IdeasPage resonated w= ith my professor and I. We both like the practical flavour of the idea; th= ere is no need for a hypothesis or any academic fluff (beyond my own submit= ted report). I'm sending this email to see if anyone is already working on this, and als= o to open this to any feedback/guidance others may have. Ideally, the main outcome is a PR into https://github.com/freebsd/freebsd-c= i which implements a compliance tes= t/report that can be run automatically. I am open to suggestions if there = is a more useful outcome. My goals are to simply "do something useful" for= the FreeBSD project before the end of the term, and pass my course :) -Troy Denton --_000_YQXPR01MB41685289EB353E39D8023839D3CBAYQXPR01MB4168CANP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello list,

I need a term project for a grad school OS course, and the "POSIX Comp= liance Testing" project listed at https://wiki.freebsd.org/IdeasPage&n= bsp;resonated with my professor and I.  We both like the practical flavour of the idea; there is no need for a hypothesis or any ac= ademic fluff (beyond my own submitted report).

I'm sending this email to see if anyone is already working on this, and als= o to open this to any feedback/guidance others may have.

Ideally, the main outcome is a PR into https://github.com/freebsd/freebsd-ci which implements a comp= liance test/report that can be run automatically.  I am open to sugges= tions if there is a more useful outcome.  My goals are to simply "= ;do something useful" for the FreeBSD project before the end of the term, and pass my course :)


-Troy Denton
--_000_YQXPR01MB41685289EB353E39D8023839D3CBAYQXPR01MB4168CANP_-- From nobody Wed Oct 4 15:31:29 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S0zF30x2rz4w6wj for ; Wed, 4 Oct 2023 15:31:35 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S0zF164Kgz4SxW; Wed, 4 Oct 2023 15:31:33 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=CxL6xYEJ; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::731 as permitted sender) smtp.mailfrom=markjdb@gmail.com; dmarc=none Received: by mail-qk1-x731.google.com with SMTP id af79cd13be357-7740aa4b545so155117085a.3; Wed, 04 Oct 2023 08:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696433492; x=1697038292; darn=freebsd.org; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to; bh=ilFC+wInCSyKZnRw9bTBnfl9CBODfXIXag5z9xWZN8k=; b=CxL6xYEJ/N2Xh3inWbQTjYB7m98CqokTA0quCQuM3ziUz3vHAOAT89ja8m62dfXsTs 6yhFTI4qI6dTUbvzfMKf4gBy/+5hM1EscpM+qhoSUNgGimQZIXFBdN8I9lG3/mrDlfhK +kViTi7hEuXhaFJ9zruxth5ioIu8+SXcVWGebKbeTHx/M/dP7oasEzGikDew8LLaQC4M TqC8ssJKT4s9pjY7/GvmLCFpqVhfQmPUPomFpdS4K7fgOIru3V3mwAK+LPzmk02LmEq4 wh6DlPvMyOSccK0l7KC+WOBP+ih2WuSbimA8sModAIMC+impU8SY1VG/B3EGS3vPMMUR Dwjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696433492; x=1697038292; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ilFC+wInCSyKZnRw9bTBnfl9CBODfXIXag5z9xWZN8k=; b=neYGrhWo89thnGZ9ag82ab96sGXRKGZHjeSvfoUbdtDyFZ0HvcgNpJ4xi3nkxel1i4 21qaV2BePbbHHEBCKn7mpzwsROZiHTN4LJdVxLr9yUYmPUByQGj1EnTtfRDmulqU0L5J ryUfNar6wF6x2pZf/GQ7RcE4hGwA2YMTObcbKWhzdh+8yrVaTPqewv8UlxVWa6yZjP1J 3WlUBjsIWXIYC4mTD2Dw4hxrDqCFJazSMpX3qnRYPoORGNDn+HTPEmCsEwzE0hK+n5UE zp48A/3l/zPcEYdi5J76kpRN25z5i/EQ2zf90YM2pDDhuWX606WM+v73B8U0nYhbJFg3 0yVA== X-Gm-Message-State: AOJu0YzuLuFaw4stqh1J1BOqmRwJQPvm6mdqweoCjv7w6DjH6DbKW/k8 YtjKBeWwfGJfLrAa+PscujhPX2P0SEs= X-Google-Smtp-Source: AGHT+IGvjnsmMbf9uwKDZmDjg1FdPfWgLGdwVxQrVWjKmr97MmvBRmpXz6zBzNT0AKSg2V4+VOXf9w== X-Received: by 2002:a05:620a:3909:b0:76f:2c0f:9ddb with SMTP id qr9-20020a05620a390900b0076f2c0f9ddbmr3154931qkn.8.1696433491906; Wed, 04 Oct 2023 08:31:31 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id g4-20020ae9e104000000b007743360b3fasm1345621qkm.34.2023.10.04.08.31.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Oct 2023 08:31:31 -0700 (PDT) Date: Wed, 4 Oct 2023 11:31:29 -0400 From: Mark Johnston To: freebsd-hackers@freebsd.org Cc: rmacklem@freebsd.org Subject: copy_file_range() doesn't update the atime of an empty file Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.70 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::731:from]; BLOCKLISTDE_FAIL(0.00)[192.0.220.237:server fail,2607:f8b0:4864:20::731:server fail]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4S0zF164Kgz4SxW For a while, Jenkins has been complaining that one of the tmpfs tests is failing: https://ci.freebsd.org/job/FreeBSD-main-amd64-test/23814/testReport/junit/sys.fs.tmpfs/times_test/empty/ This has been happening since commit 8113cc827611a88540736c92ced7d3a7020a1723, which converted cat(1) to use copy_file_range(2). The test in question creates an empty file, waits for a second, then cat(1)s it and checks that the file's atime was updated. After the aforementioned commit, the atime is not updated. I believe the essential difference is that a zero-length read(2) results in a call to VOP_READ(), which results in an updated atime even if no bytes were read. For instance, ffs_read() sets IN_ACCESS so long as the routine doesn't return an error. (I'm not sure if the mtime is correspondingly updated upon a zero-length write.) copy_file_range() on the other hand elides calls to VOP_READ/VOP_WRITE when copylen is 0, so the atime doesn't get updated. I wonder if we could at least change it to call VOP_READ in that scenario, as in the untested patch below. Any thoughts? diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index 4e4161ef1a7f..d60608a6d3b9 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -3499,7 +3499,7 @@ vn_generic_copy_file_range(struct vnode *invp, off_t *inoffp, xfer -= (*inoffp % blksize); } /* Loop copying the data block. */ - while (copylen > 0 && error == 0 && !eof && interrupted == 0) { + while (error == 0 && !eof && interrupted == 0) { if (copylen < xfer) xfer = copylen; error = vn_lock(invp, LK_SHARED); @@ -3511,7 +3511,7 @@ vn_generic_copy_file_range(struct vnode *invp, off_t *inoffp, curthread); VOP_UNLOCK(invp); lastblock = false; - if (error == 0 && aresid > 0) { + if (error == 0 && (xfer == 0 || aresid > 0)) { /* Stop the copy at EOF on the input file. */ xfer -= aresid; eof = true; From nobody Wed Oct 4 15:40:10 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S0zRD6kmBz4w7qw for ; Wed, 4 Oct 2023 15:40:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S0zRD4rYhz4VjZ; Wed, 4 Oct 2023 15:40:24 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f50.google.com with SMTP id ada2fe7eead31-4526b9404b0so736688137.0; Wed, 04 Oct 2023 08:40:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696434023; x=1697038823; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=X/0C217lo/sbqpIBXknhgdd9COBTytocMcZTPvNedNg=; b=eNjmclH+SLHWd+QpLSAoHRdvYR3pfqKCLqRls8ZjlYBwWLzC6IXJ83unj0QS7PAXI3 qlCHso+MiAxLmymZu6muA4kS7lyedaer7kLa1cI2z5IiauSOQ6aNeveyqQkD0g65pVfB g55ywpi8KJI704MyDJQCjDy4u+V+MJEje2A/x1n/XxnNuXNyQjLZrQ3WienAZOFERiQC E+veVssy76/iAYpJ4woJaPCIs8EGn35C6Tt8G1vLWHOzj6TPCYihsMKHb2LRlmtX9phe Swiy5xErPgV5b0YQTj1OuoK/mrAaUZsDAzJ2LMXr2ZFoAVkOFBBhvXg+7uiXWkTYOdWf ZPig== X-Gm-Message-State: AOJu0YwY5Iu5yADb0FJZ3FiNE5h45vRv2PD8LXNzOc3Ztho6FvPLx5c5 R0+qW9xdXuSXToT4tdiy2Aa5SzGbB+6Y1WOacNuw9e+C5NM= X-Google-Smtp-Source: AGHT+IFSHYEmQ4QbmzPOpRq3MHk21kR96b6mL0eoTCxoQXwx6xCEfC5qAk5uUhu5nXFgxjpE7P9WpqIf5BYhzGSHuNI= X-Received: by 2002:a67:ee49:0:b0:452:d5cb:a211 with SMTP id g9-20020a67ee49000000b00452d5cba211mr848vsp.15.1696434022336; Wed, 04 Oct 2023 08:40:22 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Wed, 4 Oct 2023 08:40:10 -0700 Message-ID: Subject: Re: copy_file_range() doesn't update the atime of an empty file To: Mark Johnston Cc: freebsd-hackers@freebsd.org, rmacklem@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4S0zRD4rYhz4VjZ On Wed, Oct 4, 2023 at 8:31=E2=80=AFAM Mark Johnston wr= ote: > > For a while, Jenkins has been complaining that one of the tmpfs tests is > failing: > https://ci.freebsd.org/job/FreeBSD-main-amd64-test/23814/testReport/junit= /sys.fs.tmpfs/times_test/empty/ > > This has been happening since commit > 8113cc827611a88540736c92ced7d3a7020a1723, which converted cat(1) to use > copy_file_range(2). The test in question creates an empty file, waits > for a second, then cat(1)s it and checks that the file's atime was > updated. After the aforementioned commit, the atime is not updated. > > I believe the essential difference is that a zero-length read(2) results > in a call to VOP_READ(), which results in an updated atime even if no > bytes were read. For instance, ffs_read() sets IN_ACCESS so long as the > routine doesn't return an error. (I'm not sure if the mtime is > correspondingly updated upon a zero-length write.) > > copy_file_range() on the other hand elides calls to VOP_READ/VOP_WRITE > when copylen is 0, so the atime doesn't get updated. I wonder if we > could at least change it to call VOP_READ in that scenario, as in the > untested patch below. Any thoughts? > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > index 4e4161ef1a7f..d60608a6d3b9 100644 > --- a/sys/kern/vfs_vnops.c > +++ b/sys/kern/vfs_vnops.c > @@ -3499,7 +3499,7 @@ vn_generic_copy_file_range(struct vnode *invp, off_= t *inoffp, > xfer -=3D (*inoffp % blksize); > } > /* Loop copying the data block. */ > - while (copylen > 0 && error =3D=3D 0 && !eof && interrupt= ed =3D=3D 0) { > + while (error =3D=3D 0 && !eof && interrupted =3D=3D 0) { > if (copylen < xfer) > xfer =3D copylen; > error =3D vn_lock(invp, LK_SHARED); > @@ -3511,7 +3511,7 @@ vn_generic_copy_file_range(struct vnode *invp, off_= t *inoffp, > curthread); > VOP_UNLOCK(invp); > lastblock =3D false; > - if (error =3D=3D 0 && aresid > 0) { > + if (error =3D=3D 0 && (xfer =3D=3D 0 || aresid > = 0)) { > /* Stop the copy at EOF on the input file= . */ > xfer -=3D aresid; > eof =3D true; > >From POSIX: "Note that a read() of zero bytes does not modify the last data access timestamp. A read() that requests more than zero bytes, but returns zero, is required to modify the last data access timestamp." While copy_file_range is not standardized, it ought to comport to POSIX as closely as possible. I think we should change it as you suggest. From nobody Wed Oct 4 23:39:22 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S1B472QSqz4wgNl for ; Wed, 4 Oct 2023 23:39:35 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S1B464Hd9z4gt6; Wed, 4 Oct 2023 23:39:34 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="k/NbmUl4"; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-27751ac0653so258406a91.3; Wed, 04 Oct 2023 16:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696462773; x=1697067573; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=axqlC1rm/jRffZiQDVToWtEwBKHMxXRjJgaDlbyY5YQ=; b=k/NbmUl4IsY97Ku+OgaHPd0u4Hb6AME2LEh71YW1EX1eCQcwnXbY4ZqLvm3XIq+6Bc dobcVkUCN6zBChW9gkY3MTJfr7of5/HbtjiMuCPs4fW/Ug9mfYQCaO6XuNDrssC98xPu wqF2WfjWkj+Ss22G5KxWNqF+bNmnJJpCRmmjLNjEtvkbdAUBH1sRy7Tq8n6Hirp+PZMg hwiEAkJGBGO03GoWLjsCC2Q9VgtkSkRxWxBR3Jid+A0pMTZZBeDyTOMQOyDlR6i9NGFF B466SPlwq+8vhrFWnwBS/a6F7yOIrueUAbsfX2bRyNpV4khXCFDfBWD7Pti72beGCIWH E/wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696462773; x=1697067573; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=axqlC1rm/jRffZiQDVToWtEwBKHMxXRjJgaDlbyY5YQ=; b=snIdNnOrmAO26jALs5vsMTfNaQ02LVxCbTFC0KkZmKRqJk65I53ig4J+Kr8+a+0KGI 7smJdUI/mvqZfQdJ9wbsddXBHp/2ThkzcFuQAvDpqAcL6wjbyH0UDVBtoWooa5pdMQGR bEhrNOwmZt96HBd4S/qy/iuVCs5fPWqTY07m0fRo/oqaiUb010SwS0eJhSgU9Xcpz3x7 UsZ/D6aOKhqEUyaRzQfyLmDT2SRZT+6lCHDMu+mMRD/qh0vex4Xe468hsfyZcORSZO5k v+kXdDs6iuYlOUjBPimQXYJ0fyofyjXypojkOk8wlxglapGxj8lxYTXP5mwo0CZj9+b6 SZXA== X-Gm-Message-State: AOJu0YwrB2U/Z/LutWiuOIaDxrBk7w1yNxbFNPGhSIYDRwvFOc41EE9u 1Q9OLP3ATYQ+S4861Qub7IEzaNVghDWsWeAHhn4HU3g= X-Google-Smtp-Source: AGHT+IEAWpWHYeUmQamqUCChYETzxv329Xce7r1RRng6D6biDoNZUmNtqE80YPSaljHmbRobjvl6+qU5pFL1jqhnqQU= X-Received: by 2002:a17:90b:180d:b0:26b:6095:bc3f with SMTP id lw13-20020a17090b180d00b0026b6095bc3fmr3399311pjb.33.1696462773359; Wed, 04 Oct 2023 16:39:33 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Wed, 4 Oct 2023 16:39:22 -0700 Message-ID: Subject: Re: copy_file_range() doesn't update the atime of an empty file To: Alan Somers Cc: Mark Johnston , freebsd-hackers@freebsd.org, rmacklem@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.956]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1030:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TAGGED_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4S1B464Hd9z4gt6 Resent now that I am subscribed to freebsd-hackers@, On Wed, Oct 4, 2023 at 4:25=E2=80=AFPM Rick Macklem wrote: > > On Wed, Oct 4, 2023 at 8:40=E2=80=AFAM Alan Somers = wrote: > > > > CAUTION: This email originated from outside of the University of Guelph= . Do not click links or open attachments unless you recognize the sender an= d know the content is safe. If in doubt, forward suspicious emails to IThel= p@uoguelph.ca. > > > > > > On Wed, Oct 4, 2023 at 8:31=E2=80=AFAM Mark Johnston wrote: > > > > > > For a while, Jenkins has been complaining that one of the tmpfs tests= is > > > failing: > > > https://ci.freebsd.org/job/FreeBSD-main-amd64-test/23814/testReport/j= unit/sys.fs.tmpfs/times_test/empty/ > > > > > > This has been happening since commit > > > 8113cc827611a88540736c92ced7d3a7020a1723, which converted cat(1) to u= se > > > copy_file_range(2). The test in question creates an empty file, wait= s > > > for a second, then cat(1)s it and checks that the file's atime was > > > updated. After the aforementioned commit, the atime is not updated. > > > > > > I believe the essential difference is that a zero-length read(2) resu= lts > > > in a call to VOP_READ(), which results in an updated atime even if no > > > bytes were read. For instance, ffs_read() sets IN_ACCESS so long as = the > > > routine doesn't return an error. (I'm not sure if the mtime is > > > correspondingly updated upon a zero-length write.) > > > > > > copy_file_range() on the other hand elides calls to VOP_READ/VOP_WRIT= E > > > when copylen is 0, so the atime doesn't get updated. I wonder if we > > > could at least change it to call VOP_READ in that scenario, as in the > > > untested patch below. Any thoughts? > > > > > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > > > index 4e4161ef1a7f..d60608a6d3b9 100644 > > > --- a/sys/kern/vfs_vnops.c > > > +++ b/sys/kern/vfs_vnops.c > > > @@ -3499,7 +3499,7 @@ vn_generic_copy_file_range(struct vnode *invp, = off_t *inoffp, > > > xfer -=3D (*inoffp % blksize); > > > } > > > /* Loop copying the data block. */ > > > - while (copylen > 0 && error =3D=3D 0 && !eof && inter= rupted =3D=3D 0) { > > > + while (error =3D=3D 0 && !eof && interrupted =3D=3D 0= ) { > > > if (copylen < xfer) > > > xfer =3D copylen; > > > error =3D vn_lock(invp, LK_SHARED); > > > @@ -3511,7 +3511,7 @@ vn_generic_copy_file_range(struct vnode *invp, = off_t *inoffp, > > > curthread); > > > VOP_UNLOCK(invp); > > > lastblock =3D false; > > > - if (error =3D=3D 0 && aresid > 0) { > > > + if (error =3D=3D 0 && (xfer =3D=3D 0 || aresi= d > 0)) { > > > /* Stop the copy at EOF on the input = file. */ > > > xfer -=3D aresid; > > > eof =3D true; > > > > > > > From POSIX: "Note that a read() of zero bytes does not modify the last > > data access timestamp. A read() that requests more than zero bytes, > > but returns zero, is required to modify the last data access > > timestamp." > > > > While copy_file_range is not standardized, it ought to comport to > > POSIX as closely as possible. I think we should change it as you > > suggest. > Well, I'd like to maintain the syscall as "Linux compatible", which was > my original intent. (I consider Linux as the defacto standard for *nix* l= ike > operating systems). > > I've been ignoring a recent request for support for non-regular files for > this reason. (I eventually intend to patch the man page to clarify that > it only works for regular files, which is what Linux does.) > > As such, the first step is to figure out if Linux updates atime when a > copy_file_range() returns 0 bytes. I just did a test on Linux (kernel > version 6.3) > using a ext4 fs mounted "relatime" and doing a copy_file_range(2) on it > (using a trivial file copy program suing copy_file_range(2)) did not upda= te > atime. (I did modify the file via "cat /dev/null > file" so that the atim= e would > be updated for "relatime". A similar test using "cp" did update the atime= .) > > Also, the above changes the "generic" copy loop, but changes will > also be required (or at least tested) for ZFS when block cloning is > enabled and NFSv4.2. The NFSv4.2 RFC does not specify whether > or not a "Copy" operation that returns 0 bytes updates atime > (called TimeAccess in NFSv4.2). > Oh, and the NFS protocol (up to and including NFSv4.2) cannot > provide a POSIX compliant file system (the NFS client tries to make > it look close to POSIX compliant). As such, expecting a copy_file_range(= 2) > over NFSv4.2 to behave in a POSIX-like way may not make sense? > > Personally, I'd rather see copy_file_range(2) remain Linux compatible. > Does cat(1) really need to exhibit this behaviour or is it just read(2) > that specifies this? > > rick From nobody Thu Oct 5 14:52:55 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S1ZLD6jQHz4wvRV for ; Thu, 5 Oct 2023 14:53:08 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S1ZLC4Jk2z4TVP; Thu, 5 Oct 2023 14:53:07 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=K2DOMe5t; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::1031 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-2791747288cso803216a91.0; Thu, 05 Oct 2023 07:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696517586; x=1697122386; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=E1O4My+Q3LapeAkGyoRcrbz77ocJmtEmYM2/9obA+xs=; b=K2DOMe5tBh2WrQTxZ0q/WH5ZelWiIV9ZYxjCCPe+omRgEn84jjfbrh+2GS7rtpmyQq dROmUauYEywe771WQymw5Sp8Lmap47lOKoHWSZy+eR7QoaYrnXjgR2QvWE0MNsHV64EA vpv9UmWlDkPEsMmgGP8QO9p6AyHUsipBx1QLjvRPHqC4eanT8W+E2fe5sPLfCh2ztYcW p44AM61YdbER6nwINDnf2LESknmJsSy6wITOeSf4x7CRj9kfg08AAFGJM2eb9M5ArV4H TJbuT80yqPmtq76hpaK52qvuVegHHafhBDlOWEcVWXcT898jEoOqgEgOMKZ7npJdaVGP 4g6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696517586; x=1697122386; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=E1O4My+Q3LapeAkGyoRcrbz77ocJmtEmYM2/9obA+xs=; b=GIN7FiDO3SGNY+wZK1Mno8LFVsg00oHbtoK4xV8JxsL4u70T5UOnJUJDE5OSE82/MR Qc5jmdx9RnzyqPEUGlUBZGeTpic6l5ZGkiw5CYsvx7AG+LxFBpJTy+3/LRDpLHmiXKZL LYRxQ7xgSJNYWwc8WkPhiI/JoWCBKwIJpo+fSr+/5CSK/A+Dlyr1aO6N0A+Qq9YPQNWW l3II8GCa/nD1imSrhohGhfPkzQpmReyjDj2/WHCm/tIwNPKcdkd5VWmB4/5QIRMowzW5 wxWq9H7GWleumRX0IAvaTvRvuyLqignRHQRoBQ68OpfBXufbUXvYxsDzs+wSSK0iayBF Id6g== X-Gm-Message-State: AOJu0YywX1QHv+BWH7c8EVCZUU2PovIWVULz8LsnEo+mX0hVfpqEdhDg wFKqFovAe0fkgHa+2tSjd7QfYQPM6n7DgW006lq5TY8= X-Google-Smtp-Source: AGHT+IGoj9TiUjnQaWOluAPXqK7P20J93bOQYhupAf2fOdocGH5buaYCAjaqBtXqIjbKROsq/iK66+bJ2ytx2xVQidc= X-Received: by 2002:a17:90a:d510:b0:274:98c4:b6e7 with SMTP id t16-20020a17090ad51000b0027498c4b6e7mr4904721pju.24.1696517586093; Thu, 05 Oct 2023 07:53:06 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Thu, 5 Oct 2023 07:52:55 -0700 Message-ID: Subject: Re: copy_file_range() doesn't update the atime of an empty file To: Alan Somers Cc: Mark Johnston , freebsd-hackers@freebsd.org, rmacklem@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.74 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.74)[-0.744]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1031:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TAGGED_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4S1ZLC4Jk2z4TVP Note that, although i'd prefer to keep copy_file_range(2) Linux compatible, I would like to hear others chime in w.r.t. their preference. rick On Wed, Oct 4, 2023 at 4:39=E2=80=AFPM Rick Macklem wrote: > > Resent now that I am subscribed to freebsd-hackers@, > > On Wed, Oct 4, 2023 at 4:25=E2=80=AFPM Rick Macklem wrote: > > > > On Wed, Oct 4, 2023 at 8:40=E2=80=AFAM Alan Somers wrote: > > > > > > CAUTION: This email originated from outside of the University of Guel= ph. Do not click links or open attachments unless you recognize the sender = and know the content is safe. If in doubt, forward suspicious emails to ITh= elp@uoguelph.ca. > > > > > > > > > On Wed, Oct 4, 2023 at 8:31=E2=80=AFAM Mark Johnston wrote: > > > > > > > > For a while, Jenkins has been complaining that one of the tmpfs tes= ts is > > > > failing: > > > > https://ci.freebsd.org/job/FreeBSD-main-amd64-test/23814/testReport= /junit/sys.fs.tmpfs/times_test/empty/ > > > > > > > > This has been happening since commit > > > > 8113cc827611a88540736c92ced7d3a7020a1723, which converted cat(1) to= use > > > > copy_file_range(2). The test in question creates an empty file, wa= its > > > > for a second, then cat(1)s it and checks that the file's atime was > > > > updated. After the aforementioned commit, the atime is not updated= . > > > > > > > > I believe the essential difference is that a zero-length read(2) re= sults > > > > in a call to VOP_READ(), which results in an updated atime even if = no > > > > bytes were read. For instance, ffs_read() sets IN_ACCESS so long a= s the > > > > routine doesn't return an error. (I'm not sure if the mtime is > > > > correspondingly updated upon a zero-length write.) > > > > > > > > copy_file_range() on the other hand elides calls to VOP_READ/VOP_WR= ITE > > > > when copylen is 0, so the atime doesn't get updated. I wonder if w= e > > > > could at least change it to call VOP_READ in that scenario, as in t= he > > > > untested patch below. Any thoughts? > > > > > > > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > > > > index 4e4161ef1a7f..d60608a6d3b9 100644 > > > > --- a/sys/kern/vfs_vnops.c > > > > +++ b/sys/kern/vfs_vnops.c > > > > @@ -3499,7 +3499,7 @@ vn_generic_copy_file_range(struct vnode *invp= , off_t *inoffp, > > > > xfer -=3D (*inoffp % blksize); > > > > } > > > > /* Loop copying the data block. */ > > > > - while (copylen > 0 && error =3D=3D 0 && !eof && int= errupted =3D=3D 0) { > > > > + while (error =3D=3D 0 && !eof && interrupted =3D=3D= 0) { > > > > if (copylen < xfer) > > > > xfer =3D copylen; > > > > error =3D vn_lock(invp, LK_SHARED); > > > > @@ -3511,7 +3511,7 @@ vn_generic_copy_file_range(struct vnode *invp= , off_t *inoffp, > > > > curthread); > > > > VOP_UNLOCK(invp); > > > > lastblock =3D false; > > > > - if (error =3D=3D 0 && aresid > 0) { > > > > + if (error =3D=3D 0 && (xfer =3D=3D 0 || are= sid > 0)) { > > > > /* Stop the copy at EOF on the inpu= t file. */ > > > > xfer -=3D aresid; > > > > eof =3D true; > > > > > > > > > > From POSIX: "Note that a read() of zero bytes does not modify the las= t > > > data access timestamp. A read() that requests more than zero bytes, > > > but returns zero, is required to modify the last data access > > > timestamp." > > > > > > While copy_file_range is not standardized, it ought to comport to > > > POSIX as closely as possible. I think we should change it as you > > > suggest. > > Well, I'd like to maintain the syscall as "Linux compatible", which was > > my original intent. (I consider Linux as the defacto standard for *nix*= like > > operating systems). > > > > I've been ignoring a recent request for support for non-regular files f= or > > this reason. (I eventually intend to patch the man page to clarify tha= t > > it only works for regular files, which is what Linux does.) > > > > As such, the first step is to figure out if Linux updates atime when a > > copy_file_range() returns 0 bytes. I just did a test on Linux (kernel > > version 6.3) > > using a ext4 fs mounted "relatime" and doing a copy_file_range(2) on it > > (using a trivial file copy program suing copy_file_range(2)) did not up= date > > atime. (I did modify the file via "cat /dev/null > file" so that the at= ime would > > be updated for "relatime". A similar test using "cp" did update the ati= me.) > > > > Also, the above changes the "generic" copy loop, but changes will > > also be required (or at least tested) for ZFS when block cloning is > > enabled and NFSv4.2. The NFSv4.2 RFC does not specify whether > > or not a "Copy" operation that returns 0 bytes updates atime > > (called TimeAccess in NFSv4.2). > > Oh, and the NFS protocol (up to and including NFSv4.2) cannot > > provide a POSIX compliant file system (the NFS client tries to make > > it look close to POSIX compliant). As such, expecting a copy_file_rang= e(2) > > over NFSv4.2 to behave in a POSIX-like way may not make sense? > > > > Personally, I'd rather see copy_file_range(2) remain Linux compatible. > > Does cat(1) really need to exhibit this behaviour or is it just read(2) > > that specifies this? > > > > rick From nobody Thu Oct 5 15:41:16 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S1bQ41LPmz4vpFw for ; Thu, 5 Oct 2023 15:41:32 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S1bQ31ThTz3J3Q; Thu, 5 Oct 2023 15:41:31 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.222.50 as permitted sender) smtp.mailfrom=asomers@gmail.com; dmarc=none Received: by mail-ua1-f50.google.com with SMTP id a1e0cc1a2514c-7abbe1067d1so462946241.0; Thu, 05 Oct 2023 08:41:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696520490; x=1697125290; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fWXwfkRcbSs3kS8WvDAS6WjJ6/R8mTHN9gYOuBmDhjs=; b=Rm44C1lQUaaDZzei4ELXMcqlEzrhRJu2ufXwE/utr/ygB/AvZnCZpGWJircqb/MyXF c4n08ZjiX0CeBmIlwAOqiiWe94OWm2mcnDb0+DSfKl3FHx+M+/9rHfIFPDGhsMqClXap FOMiG7bEJgS2kBEaIzgym4JgTnMoL0eAyhS+mlskkfjUrJySXp93L9Z2cgTlbnSGTv+W 7iRvC0Wrkm5b3QxWVkaWGwyKXo6ecZy6yCIksrS0mowL64pnn+ExZTmdoQyOew5cExc0 DpiUm/lG8Of3HtaKvHFCrHf6lKxaTMDr5TCidvwQtjurkh6gnl/pT3x2PtLFTxKEhwT7 dW6w== X-Gm-Message-State: AOJu0YyBCrR07iXqa953sNjNkR/vc6tZC4LBTiv2QwwiuC+RMMx99zNG WwuAgfIHiQh7AGMk9eB9EiaaF4d4v23o1p9VSAgElW70 X-Google-Smtp-Source: AGHT+IFYbI2eQbYk6Q05be3vwi0mhRNbx+a+zlnjb2vrVrcjiWHgg/e2GzaHPyFJtnf+B7HyTwavXJKGMttvzDxp3Zg= X-Received: by 2002:a67:b641:0:b0:44d:4b8d:31e5 with SMTP id e1-20020a67b641000000b0044d4b8d31e5mr4591200vsm.35.1696520489691; Thu, 05 Oct 2023 08:41:29 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Thu, 5 Oct 2023 08:41:16 -0700 Message-ID: Subject: Re: copy_file_range() doesn't update the atime of an empty file To: Rick Macklem Cc: Mark Johnston , freebsd-hackers@freebsd.org, rmacklem@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.52 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.52)[-0.516]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.50:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.50:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[asomers]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCPT_COUNT_THREE(0.00)[4]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com] X-Rspamd-Queue-Id: 4S1bQ31ThTz3J3Q I don't think that Linux is a good model to copy from, where atime is concerned. It long ago gave up on POSIX-compliance for atime by default. In this case, I think it's better to stick as closely as we can to read(2). Preserving the existing behavior of tools like cat, too, is worthwhile I think. On Thu, Oct 5, 2023 at 7:53=E2=80=AFAM Rick Macklem wrote: > > Note that, although i'd prefer to keep copy_file_range(2) Linux compatibl= e, > I would like to hear others chime in w.r.t. their preference. > > rick > > On Wed, Oct 4, 2023 at 4:39=E2=80=AFPM Rick Macklem wrote: > > > > Resent now that I am subscribed to freebsd-hackers@, > > > > On Wed, Oct 4, 2023 at 4:25=E2=80=AFPM Rick Macklem wrote: > > > > > > On Wed, Oct 4, 2023 at 8:40=E2=80=AFAM Alan Somers wrote: > > > > > > > > CAUTION: This email originated from outside of the University of Gu= elph. Do not click links or open attachments unless you recognize the sende= r and know the content is safe. If in doubt, forward suspicious emails to I= Thelp@uoguelph.ca. > > > > > > > > > > > > On Wed, Oct 4, 2023 at 8:31=E2=80=AFAM Mark Johnston wrote: > > > > > > > > > > For a while, Jenkins has been complaining that one of the tmpfs t= ests is > > > > > failing: > > > > > https://ci.freebsd.org/job/FreeBSD-main-amd64-test/23814/testRepo= rt/junit/sys.fs.tmpfs/times_test/empty/ > > > > > > > > > > This has been happening since commit > > > > > 8113cc827611a88540736c92ced7d3a7020a1723, which converted cat(1) = to use > > > > > copy_file_range(2). The test in question creates an empty file, = waits > > > > > for a second, then cat(1)s it and checks that the file's atime wa= s > > > > > updated. After the aforementioned commit, the atime is not updat= ed. > > > > > > > > > > I believe the essential difference is that a zero-length read(2) = results > > > > > in a call to VOP_READ(), which results in an updated atime even i= f no > > > > > bytes were read. For instance, ffs_read() sets IN_ACCESS so long= as the > > > > > routine doesn't return an error. (I'm not sure if the mtime is > > > > > correspondingly updated upon a zero-length write.) > > > > > > > > > > copy_file_range() on the other hand elides calls to VOP_READ/VOP_= WRITE > > > > > when copylen is 0, so the atime doesn't get updated. I wonder if= we > > > > > could at least change it to call VOP_READ in that scenario, as in= the > > > > > untested patch below. Any thoughts? > > > > > > > > > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > > > > > index 4e4161ef1a7f..d60608a6d3b9 100644 > > > > > --- a/sys/kern/vfs_vnops.c > > > > > +++ b/sys/kern/vfs_vnops.c > > > > > @@ -3499,7 +3499,7 @@ vn_generic_copy_file_range(struct vnode *in= vp, off_t *inoffp, > > > > > xfer -=3D (*inoffp % blksize); > > > > > } > > > > > /* Loop copying the data block. */ > > > > > - while (copylen > 0 && error =3D=3D 0 && !eof && i= nterrupted =3D=3D 0) { > > > > > + while (error =3D=3D 0 && !eof && interrupted =3D= =3D 0) { > > > > > if (copylen < xfer) > > > > > xfer =3D copylen; > > > > > error =3D vn_lock(invp, LK_SHARED); > > > > > @@ -3511,7 +3511,7 @@ vn_generic_copy_file_range(struct vnode *in= vp, off_t *inoffp, > > > > > curthread); > > > > > VOP_UNLOCK(invp); > > > > > lastblock =3D false; > > > > > - if (error =3D=3D 0 && aresid > 0) { > > > > > + if (error =3D=3D 0 && (xfer =3D=3D 0 || a= resid > 0)) { > > > > > /* Stop the copy at EOF on the in= put file. */ > > > > > xfer -=3D aresid; > > > > > eof =3D true; > > > > > > > > > > > > > From POSIX: "Note that a read() of zero bytes does not modify the l= ast > > > > data access timestamp. A read() that requests more than zero bytes, > > > > but returns zero, is required to modify the last data access > > > > timestamp." > > > > > > > > While copy_file_range is not standardized, it ought to comport to > > > > POSIX as closely as possible. I think we should change it as you > > > > suggest. > > > Well, I'd like to maintain the syscall as "Linux compatible", which w= as > > > my original intent. (I consider Linux as the defacto standard for *ni= x* like > > > operating systems). > > > > > > I've been ignoring a recent request for support for non-regular files= for > > > this reason. (I eventually intend to patch the man page to clarify t= hat > > > it only works for regular files, which is what Linux does.) > > > > > > As such, the first step is to figure out if Linux updates atime when = a > > > copy_file_range() returns 0 bytes. I just did a test on Linux (kernel > > > version 6.3) > > > using a ext4 fs mounted "relatime" and doing a copy_file_range(2) on = it > > > (using a trivial file copy program suing copy_file_range(2)) did not = update > > > atime. (I did modify the file via "cat /dev/null > file" so that the = atime would > > > be updated for "relatime". A similar test using "cp" did update the a= time.) > > > > > > Also, the above changes the "generic" copy loop, but changes will > > > also be required (or at least tested) for ZFS when block cloning is > > > enabled and NFSv4.2. The NFSv4.2 RFC does not specify whether > > > or not a "Copy" operation that returns 0 bytes updates atime > > > (called TimeAccess in NFSv4.2). > > > Oh, and the NFS protocol (up to and including NFSv4.2) cannot > > > provide a POSIX compliant file system (the NFS client tries to make > > > it look close to POSIX compliant). As such, expecting a copy_file_ra= nge(2) > > > over NFSv4.2 to behave in a POSIX-like way may not make sense? > > > > > > Personally, I'd rather see copy_file_range(2) remain Linux compatible= . > > > Does cat(1) really need to exhibit this behaviour or is it just read(= 2) > > > that specifies this? > > > > > > rick From nobody Thu Oct 5 17:14:27 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S1dTZ30zFz4w69d for ; Thu, 5 Oct 2023 17:14:42 +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 4S1dTY5yBTz3bVx; Thu, 5 Oct 2023 17:14:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 395HERN9084719 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 5 Oct 2023 20:14:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 395HERN9084719 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 395HERkB084718; Thu, 5 Oct 2023 20:14:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Oct 2023 20:14:27 +0300 From: Konstantin Belousov To: Alan Somers Cc: Rick Macklem , Mark Johnston , freebsd-hackers@freebsd.org, rmacklem@freebsd.org Subject: Re: copy_file_range() doesn't update the atime of an empty file Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4S1dTY5yBTz3bVx On Thu, Oct 05, 2023 at 08:41:16AM -0700, Alan Somers wrote: > I don't think that Linux is a good model to copy from, where atime is > concerned. It long ago gave up on POSIX-compliance for atime by > default. In this case, I think it's better to stick as closely as we > can to read(2). Preserving the existing behavior of tools like cat, > too, is worthwhile I think. I agree with Alan. > > On Thu, Oct 5, 2023 at 7:53 AM Rick Macklem wrote: > > > > Note that, although i'd prefer to keep copy_file_range(2) Linux compatible, > > I would like to hear others chime in w.r.t. their preference. > > > > rick > > > > On Wed, Oct 4, 2023 at 4:39 PM Rick Macklem wrote: > > > > > > Resent now that I am subscribed to freebsd-hackers@, > > > > > > On Wed, Oct 4, 2023 at 4:25 PM Rick Macklem wrote: > > > > > > > > On Wed, Oct 4, 2023 at 8:40 AM Alan Somers wrote: > > > > > > > > > > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca. > > > > > > > > > > > > > > > On Wed, Oct 4, 2023 at 8:31 AM Mark Johnston wrote: > > > > > > > > > > > > For a while, Jenkins has been complaining that one of the tmpfs tests is > > > > > > failing: > > > > > > https://ci.freebsd.org/job/FreeBSD-main-amd64-test/23814/testReport/junit/sys.fs.tmpfs/times_test/empty/ > > > > > > > > > > > > This has been happening since commit > > > > > > 8113cc827611a88540736c92ced7d3a7020a1723, which converted cat(1) to use > > > > > > copy_file_range(2). The test in question creates an empty file, waits > > > > > > for a second, then cat(1)s it and checks that the file's atime was > > > > > > updated. After the aforementioned commit, the atime is not updated. > > > > > > > > > > > > I believe the essential difference is that a zero-length read(2) results > > > > > > in a call to VOP_READ(), which results in an updated atime even if no > > > > > > bytes were read. For instance, ffs_read() sets IN_ACCESS so long as the > > > > > > routine doesn't return an error. (I'm not sure if the mtime is > > > > > > correspondingly updated upon a zero-length write.) > > > > > > > > > > > > copy_file_range() on the other hand elides calls to VOP_READ/VOP_WRITE > > > > > > when copylen is 0, so the atime doesn't get updated. I wonder if we > > > > > > could at least change it to call VOP_READ in that scenario, as in the > > > > > > untested patch below. Any thoughts? > > > > > > > > > > > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > > > > > > index 4e4161ef1a7f..d60608a6d3b9 100644 > > > > > > --- a/sys/kern/vfs_vnops.c > > > > > > +++ b/sys/kern/vfs_vnops.c > > > > > > @@ -3499,7 +3499,7 @@ vn_generic_copy_file_range(struct vnode *invp, off_t *inoffp, > > > > > > xfer -= (*inoffp % blksize); > > > > > > } > > > > > > /* Loop copying the data block. */ > > > > > > - while (copylen > 0 && error == 0 && !eof && interrupted == 0) { > > > > > > + while (error == 0 && !eof && interrupted == 0) { > > > > > > if (copylen < xfer) > > > > > > xfer = copylen; > > > > > > error = vn_lock(invp, LK_SHARED); > > > > > > @@ -3511,7 +3511,7 @@ vn_generic_copy_file_range(struct vnode *invp, off_t *inoffp, > > > > > > curthread); > > > > > > VOP_UNLOCK(invp); > > > > > > lastblock = false; > > > > > > - if (error == 0 && aresid > 0) { > > > > > > + if (error == 0 && (xfer == 0 || aresid > 0)) { > > > > > > /* Stop the copy at EOF on the input file. */ > > > > > > xfer -= aresid; > > > > > > eof = true; > > > > > > > > > > > > > > > > From POSIX: "Note that a read() of zero bytes does not modify the last > > > > > data access timestamp. A read() that requests more than zero bytes, > > > > > but returns zero, is required to modify the last data access > > > > > timestamp." > > > > > > > > > > While copy_file_range is not standardized, it ought to comport to > > > > > POSIX as closely as possible. I think we should change it as you > > > > > suggest. > > > > Well, I'd like to maintain the syscall as "Linux compatible", which was > > > > my original intent. (I consider Linux as the defacto standard for *nix* like > > > > operating systems). > > > > > > > > I've been ignoring a recent request for support for non-regular files for > > > > this reason. (I eventually intend to patch the man page to clarify that > > > > it only works for regular files, which is what Linux does.) > > > > > > > > As such, the first step is to figure out if Linux updates atime when a > > > > copy_file_range() returns 0 bytes. I just did a test on Linux (kernel > > > > version 6.3) > > > > using a ext4 fs mounted "relatime" and doing a copy_file_range(2) on it > > > > (using a trivial file copy program suing copy_file_range(2)) did not update > > > > atime. (I did modify the file via "cat /dev/null > file" so that the atime would > > > > be updated for "relatime". A similar test using "cp" did update the atime.) > > > > > > > > Also, the above changes the "generic" copy loop, but changes will > > > > also be required (or at least tested) for ZFS when block cloning is > > > > enabled and NFSv4.2. The NFSv4.2 RFC does not specify whether > > > > or not a "Copy" operation that returns 0 bytes updates atime > > > > (called TimeAccess in NFSv4.2). > > > > Oh, and the NFS protocol (up to and including NFSv4.2) cannot > > > > provide a POSIX compliant file system (the NFS client tries to make > > > > it look close to POSIX compliant). As such, expecting a copy_file_range(2) > > > > over NFSv4.2 to behave in a POSIX-like way may not make sense? > > > > > > > > Personally, I'd rather see copy_file_range(2) remain Linux compatible. > > > > Does cat(1) really need to exhibit this behaviour or is it just read(2) > > > > that specifies this? > > > > > > > > rick > From nobody Thu Oct 5 17:17:12 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S1dXk33c5z4w6YZ for ; Thu, 5 Oct 2023 17:17:26 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (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 "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S1dXj676bz3cXR for ; Thu, 5 Oct 2023 17:17:25 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of bsd-lists@bsdforge.com has no SPF policy when checking 24.113.41.81) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 395HHCEp066943 for ; Thu, 5 Oct 2023 10:17:18 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Thu, 05 Oct 2023 10:17:12 -0700 From: Chris To: freebsd-hackers@freebsd.org Subject: Re: copy_file_range() doesn't update the atime of an empty file In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.00 / 15.00]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-Rspamd-Queue-Id: 4S1dXj676bz3cXR On 2023-10-05 08:41, Alan Somers wrote: > I don't think that Linux is a good model to copy from, where atime is > concerned. It long ago gave up on POSIX-compliance for atime by > default. In this case, I think it's better to stick as closely as we > can to read(2). Preserving the existing behavior of tools like cat, > too, is worthwhile I think. Thank you for saying this. I couldn't agree more. :-) > > On Thu, Oct 5, 2023 at 7:53 AM Rick Macklem wrote: >> >> Note that, although i'd prefer to keep copy_file_range(2) Linux compatible, >> I would like to hear others chime in w.r.t. their preference. >> >> rick >> >> On Wed, Oct 4, 2023 at 4:39 PM Rick Macklem wrote: >> > >> > Resent now that I am subscribed to freebsd-hackers@, >> > >> > On Wed, Oct 4, 2023 at 4:25 PM Rick Macklem wrote: >> > > >> > > On Wed, Oct 4, 2023 at 8:40 AM Alan Somers wrote: >> > > > >> > > > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca. >> > > > >> > > > >> > > > On Wed, Oct 4, 2023 at 8:31 AM Mark Johnston wrote: >> > > > > >> > > > > For a while, Jenkins has been complaining that one of the tmpfs tests is >> > > > > failing: >> > > > > https://ci.freebsd.org/job/FreeBSD-main-amd64-test/23814/testReport/junit/sys.fs.tmpfs/times_test/empty/ >> > > > > >> > > > > This has been happening since commit >> > > > > 8113cc827611a88540736c92ced7d3a7020a1723, which converted cat(1) to use >> > > > > copy_file_range(2). The test in question creates an empty file, waits >> > > > > for a second, then cat(1)s it and checks that the file's atime was >> > > > > updated. After the aforementioned commit, the atime is not updated. >> > > > > >> > > > > I believe the essential difference is that a zero-length read(2) results >> > > > > in a call to VOP_READ(), which results in an updated atime even if no >> > > > > bytes were read. For instance, ffs_read() sets IN_ACCESS so long as the >> > > > > routine doesn't return an error. (I'm not sure if the mtime is >> > > > > correspondingly updated upon a zero-length write.) >> > > > > >> > > > > copy_file_range() on the other hand elides calls to VOP_READ/VOP_WRITE >> > > > > when copylen is 0, so the atime doesn't get updated. I wonder if we >> > > > > could at least change it to call VOP_READ in that scenario, as in the >> > > > > untested patch below. Any thoughts? >> > > > > >> > > > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c >> > > > > index 4e4161ef1a7f..d60608a6d3b9 100644 >> > > > > --- a/sys/kern/vfs_vnops.c >> > > > > +++ b/sys/kern/vfs_vnops.c >> > > > > @@ -3499,7 +3499,7 @@ vn_generic_copy_file_range(struct vnode *invp, off_t *inoffp, >> > > > > xfer -= (*inoffp % blksize); >> > > > > } >> > > > > /* Loop copying the data block. */ >> > > > > - while (copylen > 0 && error == 0 && !eof && interrupted == 0) { >> > > > > + while (error == 0 && !eof && interrupted == 0) { >> > > > > if (copylen < xfer) >> > > > > xfer = copylen; >> > > > > error = vn_lock(invp, LK_SHARED); >> > > > > @@ -3511,7 +3511,7 @@ vn_generic_copy_file_range(struct vnode *invp, off_t *inoffp, >> > > > > curthread); >> > > > > VOP_UNLOCK(invp); >> > > > > lastblock = false; >> > > > > - if (error == 0 && aresid > 0) { >> > > > > + if (error == 0 && (xfer == 0 || aresid > 0)) { >> > > > > /* Stop the copy at EOF on the input file. */ >> > > > > xfer -= aresid; >> > > > > eof = true; >> > > > > >> > > > >> > > > From POSIX: "Note that a read() of zero bytes does not modify the last >> > > > data access timestamp. A read() that requests more than zero bytes, >> > > > but returns zero, is required to modify the last data access >> > > > timestamp." >> > > > >> > > > While copy_file_range is not standardized, it ought to comport to >> > > > POSIX as closely as possible. I think we should change it as you >> > > > suggest. >> > > Well, I'd like to maintain the syscall as "Linux compatible", which was >> > > my original intent. (I consider Linux as the defacto standard for *nix* like >> > > operating systems). >> > > >> > > I've been ignoring a recent request for support for non-regular files for >> > > this reason. (I eventually intend to patch the man page to clarify that >> > > it only works for regular files, which is what Linux does.) >> > > >> > > As such, the first step is to figure out if Linux updates atime when a >> > > copy_file_range() returns 0 bytes. I just did a test on Linux (kernel >> > > version 6.3) >> > > using a ext4 fs mounted "relatime" and doing a copy_file_range(2) on it >> > > (using a trivial file copy program suing copy_file_range(2)) did not update >> > > atime. (I did modify the file via "cat /dev/null > file" so that the atime would >> > > be updated for "relatime". A similar test using "cp" did update the atime.) >> > > >> > > Also, the above changes the "generic" copy loop, but changes will >> > > also be required (or at least tested) for ZFS when block cloning is >> > > enabled and NFSv4.2. The NFSv4.2 RFC does not specify whether >> > > or not a "Copy" operation that returns 0 bytes updates atime >> > > (called TimeAccess in NFSv4.2). >> > > Oh, and the NFS protocol (up to and including NFSv4.2) cannot >> > > provide a POSIX compliant file system (the NFS client tries to make >> > > it look close to POSIX compliant). As such, expecting a copy_file_range(2) >> > > over NFSv4.2 to behave in a POSIX-like way may not make sense? >> > > >> > > Personally, I'd rather see copy_file_range(2) remain Linux compatible. >> > > Does cat(1) really need to exhibit this behaviour or is it just read(2) >> > > that specifies this? >> > > >> > > rick From nobody Thu Oct 5 22:30:25 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S1mV61PCMz4w1sq for ; Thu, 5 Oct 2023 22:30:38 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S1mV56p08z3Kbd; Thu, 5 Oct 2023 22:30:37 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-692c70bc440so1280828b3a.3; Thu, 05 Oct 2023 15:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696545035; x=1697149835; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UZxWY3mgfDOK8vfHiH1gsEMMGZFZusn70W0thTM4YQc=; b=gzVnZkgg5Wx+2FH/o03Pbuh4Jvxcd6YJbabAX0B+PWcyAvhw/PkMRJMu2QoFyE1pxC BI4cHeU9USHKgGAY7JC2i9v0vI/09O/U3XUqtmDvEcuWFlyK7LkcMfWS6BgolDtQnEL1 EU7M22oZ9enAuy95S8orkraLapysZr9SfXaDXB6QZS0uhIgm7QnDGVgIDYIeFvDKvK0G 4x1IlUa3oE4mc3Q7U2ln7JwqnGRtVHKwnahTDtdxizgKYO2itfvBf1gBvSItsw5yfrCv 89Src17FFEqleRoiR19LdaHis5+rtFy4dP9NNt/gAHtGN4SmcJYP6PtwZjxdy22s1CCW AeZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696545035; x=1697149835; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UZxWY3mgfDOK8vfHiH1gsEMMGZFZusn70W0thTM4YQc=; b=vn7RCu0LdWWMx2orcQYjJgr0ioVFwhi/d9tcu3T4DfJSVDpDJkW8wBUOgdoHXniPYr n92dBq3nz2pcMyCBtQnxoupRBIAl6FGfJDqL8/Xtrj5N0Ax/0vD9ofOaxjGO9/CIANJP UzsnsP9Mu5ygbIP+VsFdW2+bSsQMb5xxpDuxLTL0anlC1W72UO2C07o8H8m3vhe9OTmB VqjkQp5Z+L7+yXwBnEHIxiINFcyJM+U3csEXiFQchKbldq3q5Nfuod5rkwg98ncdVpqU FfT3jS8q6FMShViJWU06fuaN0SzsYQKtGVpLEPoVnfjRiNK5u0YbtCEom/3Bn3fuyfvJ n8Dw== X-Gm-Message-State: AOJu0YzUHybNZvY1QNOaVyCtOs/xhudwat61xQ+yKK9VZ8SuM9xS2ic0 biRqwNp1Fq7QWK7azig9OTU1nPN3FfNUyf8DDjaz6hs= X-Google-Smtp-Source: AGHT+IHIGBIJopzLRL3584z1OTMfAdTJw6WuK2QdvEBP4/mpzhzOqPtd6MTbD48RSK02lJFg2MCDn0WQwxpliXedw0w= X-Received: by 2002:a17:90b:38cb:b0:274:729a:bcd9 with SMTP id nn11-20020a17090b38cb00b00274729abcd9mr6511560pjb.43.1696545035186; Thu, 05 Oct 2023 15:30:35 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Thu, 5 Oct 2023 15:30:25 -0700 Message-ID: Subject: Re: copy_file_range() doesn't update the atime of an empty file To: Alan Somers Cc: Mark Johnston , freebsd-hackers@freebsd.org, rmacklem@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Queue-Id: 4S1mV56p08z3Kbd On Thu, Oct 5, 2023 at 8:41=E2=80=AFAM Alan Somers wr= ote: > > I don't think that Linux is a good model to copy from, where atime is > concerned. It long ago gave up on POSIX-compliance for atime by > default. In this case, I think it's better to stick as closely as we > can to read(2). Preserving the existing behavior of tools like cat, > too, is worthwhile I think. I have no problem with Mark's patch being applied for the default local fs case. NFSv4.2 will not be able to comply with this unless (as will be the case for the FreeBSD server) the NFSv4.2 server happens to change atime after Mark's patch is applied to the FreeBSD NFSv4.2 server (the Linux NFSv4.2 server will not). ZFS..I have no idea. Someone else will need to test it (with block cloning enabled). rick > > On Thu, Oct 5, 2023 at 7:53=E2=80=AFAM Rick Macklem wrote: > > > > Note that, although i'd prefer to keep copy_file_range(2) Linux compati= ble, > > I would like to hear others chime in w.r.t. their preference. > > > > rick > > > > On Wed, Oct 4, 2023 at 4:39=E2=80=AFPM Rick Macklem wrote: > > > > > > Resent now that I am subscribed to freebsd-hackers@, > > > > > > On Wed, Oct 4, 2023 at 4:25=E2=80=AFPM Rick Macklem wrote: > > > > > > > > On Wed, Oct 4, 2023 at 8:40=E2=80=AFAM Alan Somers wrote: > > > > > > > > > > CAUTION: This email originated from outside of the University of = Guelph. Do not click links or open attachments unless you recognize the sen= der and know the content is safe. If in doubt, forward suspicious emails to= IThelp@uoguelph.ca. > > > > > > > > > > > > > > > On Wed, Oct 4, 2023 at 8:31=E2=80=AFAM Mark Johnston wrote: > > > > > > > > > > > > For a while, Jenkins has been complaining that one of the tmpfs= tests is > > > > > > failing: > > > > > > https://ci.freebsd.org/job/FreeBSD-main-amd64-test/23814/testRe= port/junit/sys.fs.tmpfs/times_test/empty/ > > > > > > > > > > > > This has been happening since commit > > > > > > 8113cc827611a88540736c92ced7d3a7020a1723, which converted cat(1= ) to use > > > > > > copy_file_range(2). The test in question creates an empty file= , waits > > > > > > for a second, then cat(1)s it and checks that the file's atime = was > > > > > > updated. After the aforementioned commit, the atime is not upd= ated. > > > > > > > > > > > > I believe the essential difference is that a zero-length read(2= ) results > > > > > > in a call to VOP_READ(), which results in an updated atime even= if no > > > > > > bytes were read. For instance, ffs_read() sets IN_ACCESS so lo= ng as the > > > > > > routine doesn't return an error. (I'm not sure if the mtime is > > > > > > correspondingly updated upon a zero-length write.) > > > > > > > > > > > > copy_file_range() on the other hand elides calls to VOP_READ/VO= P_WRITE > > > > > > when copylen is 0, so the atime doesn't get updated. I wonder = if we > > > > > > could at least change it to call VOP_READ in that scenario, as = in the > > > > > > untested patch below. Any thoughts? > > > > > > > > > > > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > > > > > > index 4e4161ef1a7f..d60608a6d3b9 100644 > > > > > > --- a/sys/kern/vfs_vnops.c > > > > > > +++ b/sys/kern/vfs_vnops.c > > > > > > @@ -3499,7 +3499,7 @@ vn_generic_copy_file_range(struct vnode *= invp, off_t *inoffp, > > > > > > xfer -=3D (*inoffp % blksize); > > > > > > } > > > > > > /* Loop copying the data block. */ > > > > > > - while (copylen > 0 && error =3D=3D 0 && !eof &&= interrupted =3D=3D 0) { > > > > > > + while (error =3D=3D 0 && !eof && interrupted = =3D=3D 0) { > > > > > > if (copylen < xfer) > > > > > > xfer =3D copylen; > > > > > > error =3D vn_lock(invp, LK_SHARED); > > > > > > @@ -3511,7 +3511,7 @@ vn_generic_copy_file_range(struct vnode *= invp, off_t *inoffp, > > > > > > curthread); > > > > > > VOP_UNLOCK(invp); > > > > > > lastblock =3D false; > > > > > > - if (error =3D=3D 0 && aresid > 0) { > > > > > > + if (error =3D=3D 0 && (xfer =3D=3D 0 ||= aresid > 0)) { > > > > > > /* Stop the copy at EOF on the = input file. */ > > > > > > xfer -=3D aresid; > > > > > > eof =3D true; > > > > > > > > > > > > > > > > From POSIX: "Note that a read() of zero bytes does not modify the= last > > > > > data access timestamp. A read() that requests more than zero byte= s, > > > > > but returns zero, is required to modify the last data access > > > > > timestamp." > > > > > > > > > > While copy_file_range is not standardized, it ought to comport to > > > > > POSIX as closely as possible. I think we should change it as you > > > > > suggest. > > > > Well, I'd like to maintain the syscall as "Linux compatible", which= was > > > > my original intent. (I consider Linux as the defacto standard for *= nix* like > > > > operating systems). > > > > > > > > I've been ignoring a recent request for support for non-regular fil= es for > > > > this reason. (I eventually intend to patch the man page to clarify= that > > > > it only works for regular files, which is what Linux does.) > > > > > > > > As such, the first step is to figure out if Linux updates atime whe= n a > > > > copy_file_range() returns 0 bytes. I just did a test on Linux (kern= el > > > > version 6.3) > > > > using a ext4 fs mounted "relatime" and doing a copy_file_range(2) o= n it > > > > (using a trivial file copy program suing copy_file_range(2)) did no= t update > > > > atime. (I did modify the file via "cat /dev/null > file" so that th= e atime would > > > > be updated for "relatime". A similar test using "cp" did update the= atime.) > > > > > > > > Also, the above changes the "generic" copy loop, but changes will > > > > also be required (or at least tested) for ZFS when block cloning is > > > > enabled and NFSv4.2. The NFSv4.2 RFC does not specify whether > > > > or not a "Copy" operation that returns 0 bytes updates atime > > > > (called TimeAccess in NFSv4.2). > > > > Oh, and the NFS protocol (up to and including NFSv4.2) cannot > > > > provide a POSIX compliant file system (the NFS client tries to make > > > > it look close to POSIX compliant). As such, expecting a copy_file_= range(2) > > > > over NFSv4.2 to behave in a POSIX-like way may not make sense? > > > > > > > > Personally, I'd rather see copy_file_range(2) remain Linux compatib= le. > > > > Does cat(1) really need to exhibit this behaviour or is it just rea= d(2) > > > > that specifies this? > > > > > > > > rick From nobody Fri Oct 6 01:53:04 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S1rzw4n42z4wZZK for ; Fri, 6 Oct 2023 01:53:16 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S1rzv5wNzz4JcS; Fri, 6 Oct 2023 01:53:15 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=NdsbKMCX; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-2791747288cso1251558a91.0; Thu, 05 Oct 2023 18:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696557194; x=1697161994; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HhyrelIBYf1yCuE3gjve4dLXapXlvQRQ1j/ATxyteH4=; b=NdsbKMCXBN+kr13jjcdmp62YFsQjuAeHXM7dCoNYrUPsRQIZtnu7/o3j9OE+oPfW54 WpvgKrtBAAzqDaqZ+vWxUJfMu6aZZ455fkcvmmK+xngYtY324LVW/u7hqIE97eY3yDyy Sh35ESyjQiThXlXIEBF+izRYvv9yWcNy9CSTLKI5YdeDW0XPXCy1nh7JXXqf41Mzx0tG 3/h2Io7wKA5Vdy2aNtdATvLxw1iLJ9LdZsyDxNB7HVsE1wanUYOXLT7jddmqWahpuG6Y HXmuWox/6jEbypKIG7nrHd8/zgE44ON1Jn7jLwGG9IAGMk33qwRIeS6V5l905RE0rerJ e3Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696557194; x=1697161994; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HhyrelIBYf1yCuE3gjve4dLXapXlvQRQ1j/ATxyteH4=; b=bC0Z1byFqVeGcShY4Oj2d0Z30PuBHsTnxIFXpGi1OQrQHdzcqbxNSPVqYWNcc4TOeR ZMdUDnY+e9/ui6/KaPupA4XzaBXy4wWe33xDp2zdOZd1mW9ztlIoXtScmLAwQhKgfa0u 5IEcs5GEinRhQnWIzGc28h5B3Btw6mR3NMP7GlvELteJGhJIXm4YUeZgH+/fkb7FjTDA UZ6YYdwUzYwuMYBvh00S2gm8Bqxenx1Yu56MB/059BMAbhXglI6XjZWbYG+aaM/Coh3H ZXtnCdcSp5Z8HHeSWxZJM0dd0RyyHmbQF+i2pV/4YcJ/bSakQ4vA/QKbjTayea1PFKhY R6BQ== X-Gm-Message-State: AOJu0YyGhaUyxwUnV7jFoTAjLi4OJUIaXpMsjpG8QNiGsypVKc85KJJd me07pYj3YDhtXjmKf+keDeITzxFEtCCalDF4hxR2D9s= X-Google-Smtp-Source: AGHT+IFazvNryxmJ0WSJcaD+4zPtZE9BlM5duwR2Df9F+HSPoquEPHbvlyqyXGYqLIsdXebSVnGKeKxEu0+BqV96wAk= X-Received: by 2002:a17:90b:180d:b0:26b:6095:bc3f with SMTP id lw13-20020a17090b180d00b0026b6095bc3fmr6362475pjb.33.1696557193999; Thu, 05 Oct 2023 18:53:13 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Thu, 5 Oct 2023 18:53:04 -0700 Message-ID: Subject: Re: copy_file_range() doesn't update the atime of an empty file To: Alan Somers Cc: Mark Johnston , freebsd-hackers@freebsd.org, rmacklem@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.942]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102f:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4S1rzv5wNzz4JcS On Thu, Oct 5, 2023 at 3:30=E2=80=AFPM Rick Macklem wrote: > > On Thu, Oct 5, 2023 at 8:41=E2=80=AFAM Alan Somers = wrote: > > > > I don't think that Linux is a good model to copy from, where atime is > > concerned. It long ago gave up on POSIX-compliance for atime by > > default. In this case, I think it's better to stick as closely as we > > can to read(2). Preserving the existing behavior of tools like cat, > > too, is worthwhile I think. > I have no problem with Mark's patch being applied for the default > local fs case. NFSv4.2 will not be able to comply with this unless > (as will be the case for the FreeBSD server) the NFSv4.2 server > happens to change atime after Mark's patch is applied to the > FreeBSD NFSv4.2 server (the Linux NFSv4.2 server will not). I have come up with a NFSv4.2 client patch that explicitly sets atime for the input file in the same compound RPC as the Copy. It works for a FreeBSD server without Mark's patch. If a NFSv4.2 server does not do it, we can argue that the server ignores the Setattr of atime. So, with this patch (which I will be testing against assorted servers next week (an ietf bakeathon testing event) and Mark's patch, the only case that may need more work is ZFS? rick ps: I'll admit I still doubt anyone cares about atime being set, but the collective opinion seems to be that it should be set. > > ZFS..I have no idea. Someone else will need to test it (with block clonin= g > enabled). > > rick > > > > On Thu, Oct 5, 2023 at 7:53=E2=80=AFAM Rick Macklem wrote: > > > > > > Note that, although i'd prefer to keep copy_file_range(2) Linux compa= tible, > > > I would like to hear others chime in w.r.t. their preference. > > > > > > rick > > > > > > On Wed, Oct 4, 2023 at 4:39=E2=80=AFPM Rick Macklem wrote: > > > > > > > > Resent now that I am subscribed to freebsd-hackers@, > > > > > > > > On Wed, Oct 4, 2023 at 4:25=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > On Wed, Oct 4, 2023 at 8:40=E2=80=AFAM Alan Somers wrote: > > > > > > > > > > > > CAUTION: This email originated from outside of the University o= f Guelph. Do not click links or open attachments unless you recognize the s= ender and know the content is safe. If in doubt, forward suspicious emails = to IThelp@uoguelph.ca. > > > > > > > > > > > > > > > > > > On Wed, Oct 4, 2023 at 8:31=E2=80=AFAM Mark Johnston wrote: > > > > > > > > > > > > > > For a while, Jenkins has been complaining that one of the tmp= fs tests is > > > > > > > failing: > > > > > > > https://ci.freebsd.org/job/FreeBSD-main-amd64-test/23814/test= Report/junit/sys.fs.tmpfs/times_test/empty/ > > > > > > > > > > > > > > This has been happening since commit > > > > > > > 8113cc827611a88540736c92ced7d3a7020a1723, which converted cat= (1) to use > > > > > > > copy_file_range(2). The test in question creates an empty fi= le, waits > > > > > > > for a second, then cat(1)s it and checks that the file's atim= e was > > > > > > > updated. After the aforementioned commit, the atime is not u= pdated. > > > > > > > > > > > > > > I believe the essential difference is that a zero-length read= (2) results > > > > > > > in a call to VOP_READ(), which results in an updated atime ev= en if no > > > > > > > bytes were read. For instance, ffs_read() sets IN_ACCESS so = long as the > > > > > > > routine doesn't return an error. (I'm not sure if the mtime = is > > > > > > > correspondingly updated upon a zero-length write.) > > > > > > > > > > > > > > copy_file_range() on the other hand elides calls to VOP_READ/= VOP_WRITE > > > > > > > when copylen is 0, so the atime doesn't get updated. I wonde= r if we > > > > > > > could at least change it to call VOP_READ in that scenario, a= s in the > > > > > > > untested patch below. Any thoughts? > > > > > > > > > > > > > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > > > > > > > index 4e4161ef1a7f..d60608a6d3b9 100644 > > > > > > > --- a/sys/kern/vfs_vnops.c > > > > > > > +++ b/sys/kern/vfs_vnops.c > > > > > > > @@ -3499,7 +3499,7 @@ vn_generic_copy_file_range(struct vnode= *invp, off_t *inoffp, > > > > > > > xfer -=3D (*inoffp % blksize); > > > > > > > } > > > > > > > /* Loop copying the data block. */ > > > > > > > - while (copylen > 0 && error =3D=3D 0 && !eof = && interrupted =3D=3D 0) { > > > > > > > + while (error =3D=3D 0 && !eof && interrupted = =3D=3D 0) { > > > > > > > if (copylen < xfer) > > > > > > > xfer =3D copylen; > > > > > > > error =3D vn_lock(invp, LK_SHARED); > > > > > > > @@ -3511,7 +3511,7 @@ vn_generic_copy_file_range(struct vnode= *invp, off_t *inoffp, > > > > > > > curthread); > > > > > > > VOP_UNLOCK(invp); > > > > > > > lastblock =3D false; > > > > > > > - if (error =3D=3D 0 && aresid > 0) { > > > > > > > + if (error =3D=3D 0 && (xfer =3D=3D 0 = || aresid > 0)) { > > > > > > > /* Stop the copy at EOF on th= e input file. */ > > > > > > > xfer -=3D aresid; > > > > > > > eof =3D true; > > > > > > > > > > > > > > > > > > > From POSIX: "Note that a read() of zero bytes does not modify t= he last > > > > > > data access timestamp. A read() that requests more than zero by= tes, > > > > > > but returns zero, is required to modify the last data access > > > > > > timestamp." > > > > > > > > > > > > While copy_file_range is not standardized, it ought to comport = to > > > > > > POSIX as closely as possible. I think we should change it as y= ou > > > > > > suggest. > > > > > Well, I'd like to maintain the syscall as "Linux compatible", whi= ch was > > > > > my original intent. (I consider Linux as the defacto standard for= *nix* like > > > > > operating systems). > > > > > > > > > > I've been ignoring a recent request for support for non-regular f= iles for > > > > > this reason. (I eventually intend to patch the man page to clari= fy that > > > > > it only works for regular files, which is what Linux does.) > > > > > > > > > > As such, the first step is to figure out if Linux updates atime w= hen a > > > > > copy_file_range() returns 0 bytes. I just did a test on Linux (ke= rnel > > > > > version 6.3) > > > > > using a ext4 fs mounted "relatime" and doing a copy_file_range(2)= on it > > > > > (using a trivial file copy program suing copy_file_range(2)) did = not update > > > > > atime. (I did modify the file via "cat /dev/null > file" so that = the atime would > > > > > be updated for "relatime". A similar test using "cp" did update t= he atime.) > > > > > > > > > > Also, the above changes the "generic" copy loop, but changes will > > > > > also be required (or at least tested) for ZFS when block cloning = is > > > > > enabled and NFSv4.2. The NFSv4.2 RFC does not specify whether > > > > > or not a "Copy" operation that returns 0 bytes updates atime > > > > > (called TimeAccess in NFSv4.2). > > > > > Oh, and the NFS protocol (up to and including NFSv4.2) cannot > > > > > provide a POSIX compliant file system (the NFS client tries to ma= ke > > > > > it look close to POSIX compliant). As such, expecting a copy_fil= e_range(2) > > > > > over NFSv4.2 to behave in a POSIX-like way may not make sense? > > > > > > > > > > Personally, I'd rather see copy_file_range(2) remain Linux compat= ible. > > > > > Does cat(1) really need to exhibit this behaviour or is it just r= ead(2) > > > > > that specifies this? > > > > > > > > > > rick From nobody Fri Oct 6 02:48:41 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S1tD64ZLvz4wk3P for ; Fri, 6 Oct 2023 02:48:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S1tD570xpz4Wh8; Fri, 6 Oct 2023 02:48:53 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.221.173 as permitted sender) smtp.mailfrom=asomers@gmail.com; dmarc=none Received: by mail-vk1-f173.google.com with SMTP id 71dfb90a1353d-49e035bdca7so51369e0c.2; Thu, 05 Oct 2023 19:48:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696560533; x=1697165333; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ib6HyqAOTYaFa4O6BsOnnAVGe8/ErhNNv9aPJFQOgWc=; b=xNErDFpZ5TqvpN2LZsH3V3LVOPh9AXYlYCU7bOphN3RFwJc28cvI7/FvLpj92cVqxv EGWsdbMShpYBJyAVWvxpVa7YP0ywphwXvglJLbhEXGgMpE5Qd3esgmO5qdJZDsQzaf6T iU/3ZnC9qub7fabr4k8hiT8dXvVwViYOiUq4XlgTBmeT5ugwrQm4Z446fYYHbX6MfZP+ UeDHxg68k8xkuD3b0jfG6WWoflI57BN1pEj3wWDWZAoc9SVYxs3DJ5HaAVJgpjPU+zB/ n35p89TiylKnJGAiKbHndy3GasFYnF/qytZBFfUXWsdZx2QMXLqqAunqW4FTunRDohkt HtDQ== X-Gm-Message-State: AOJu0YwDj6/7ckWCWGK4YllV+zOelDmoXG8AwCKZFOt9S9/oUxZPINLG bAqrpx4/eAJc3TivhDC4/LuNlQZA83JF9hhOjpI= X-Google-Smtp-Source: AGHT+IEjfcUZsef0KrAkSG4DBwAWhRs5gbpn1D5kyGXwh/qokIgwg8sHK1b93IxcI9j9AbhAQ9dyroCGXr0gol3Y5mU= X-Received: by 2002:a05:6122:221a:b0:49a:88a9:cac6 with SMTP id bb26-20020a056122221a00b0049a88a9cac6mr8179402vkb.11.1696560532769; Thu, 05 Oct 2023 19:48:52 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Thu, 5 Oct 2023 19:48:41 -0700 Message-ID: Subject: Re: copy_file_range() doesn't update the atime of an empty file To: Rick Macklem Cc: Mark Johnston , freebsd-hackers@freebsd.org, rmacklem@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.86 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.86)[-0.856]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.221.173:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.221.173:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[asomers]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCPT_COUNT_THREE(0.00)[4]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com] X-Rspamd-Queue-Id: 4S1tD570xpz4Wh8 On Thu, Oct 5, 2023 at 6:53=E2=80=AFPM Rick Macklem wrote: > > On Thu, Oct 5, 2023 at 3:30=E2=80=AFPM Rick Macklem wrote: > > > > On Thu, Oct 5, 2023 at 8:41=E2=80=AFAM Alan Somers wrote: > > > > > > I don't think that Linux is a good model to copy from, where atime is > > > concerned. It long ago gave up on POSIX-compliance for atime by > > > default. In this case, I think it's better to stick as closely as we > > > can to read(2). Preserving the existing behavior of tools like cat, > > > too, is worthwhile I think. > > I have no problem with Mark's patch being applied for the default > > local fs case. NFSv4.2 will not be able to comply with this unless > > (as will be the case for the FreeBSD server) the NFSv4.2 server > > happens to change atime after Mark's patch is applied to the > > FreeBSD NFSv4.2 server (the Linux NFSv4.2 server will not). > I have come up with a NFSv4.2 client patch that explicitly sets atime > for the input file in the same compound RPC as the Copy. It works for > a FreeBSD server without Mark's patch. If a NFSv4.2 server does not > do it, we can argue that the server ignores the Setattr of atime. > > So, with this patch (which I will be testing against assorted servers nex= t > week (an ietf bakeathon testing event) and Mark's patch, the only case > that may need more work is ZFS? > > rick > ps: I'll admit I still doubt anyone cares about atime being set, but the > collective opinion seems to be that it should be set. I think the fusefs copy_file_range will already do this, but I should at least add a test for it. -Alan From nobody Sat Oct 7 14:45:29 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S2p9n1JMmz4wc5y for ; Sat, 7 Oct 2023 14:50:05 +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 4S2p9l6dm1z4hqk for ; Sat, 7 Oct 2023 14:50:03 +0000 (UTC) (envelope-from wojtek@puchar.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=LNFiHIvg; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net; dmarc=none Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.17.1) with ESMTPS id 397EnFgq096756 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 7 Oct 2023 16:49:45 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1696690191; bh=NQWUN5IH96uxNzt60xOgFUC1HVwX1Vgmsg4JBwV8vQk=; h=Date:From:To:Subject; b=LNFiHIvgCcDmNrcmziPb/cvBuLqEUTKnCvYcXD3ztDQq8HxtiqjG8XFRDFKxNtrjI gbwyG0vugJGaPxIku4p6e+oErpNxS/Ldm6DsgxE+gh9BvxwIUKj4/ZdzV/HAmC6KRj zPBt/ZH/Y3OZ5ks3bN7gKj/fcskCmrUw7Pkud7N4= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 397EjU8I063586 for ; Sat, 7 Oct 2023 16:45:30 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 397EjTwb063583 for ; Sat, 7 Oct 2023 16:45:30 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sat, 7 Oct 2023 16:45:29 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: mmcsd driver - stupid question Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; DMARC_NA(0.00)[puchar.net]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4S2p9l6dm1z4hqk i have SD card reader builtin in my laptop. Works, but detects cards only at boot. sdhci_acpi0: iomem 0x81420000-0x81420fff irq 47 on acpi0 mmc0: on sdhci_acpi0 mmcsd0: 16GB at mmc0 50.0MHz/4bit/65535-block how to force rescan of mmc bus without reboot?