Received: (at 48833) by debbugs.gnu.org; 28 Sep 2022 13:36:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 28 09:36:08 2022
Received: from localhost ([127.0.0.1]:60710 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1odXEO-0003qP-6q
for submit <at> debbugs.gnu.org; Wed, 28 Sep 2022 09:36:08 -0400
Received: from sonic322-37.consmr.mail.ne1.yahoo.com ([66.163.189.60]:42046)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <lsatenstein@HIDDEN>) id 1odXEK-0003pG-Fk
for 48833 <at> debbugs.gnu.org; Wed, 28 Sep 2022 09:36:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
t=1664372158; bh=ZnLfzEQ/pTwcjZ2SutFe4uZjLDl0ENQdnzge3ab4q1c=;
h=Date:From:Reply-To:Subject:References:From:Subject:Reply-To;
b=Q848WSLSRMLrSw0PKRhuDNt6Q1upCmpgmT0NquzubmSCGTFwQfdO1PPA0ZFjCGSZ8197uC0nPSfPJMQRV3SKPzCprEODhunZTROQmZefGU/sqG1iF5AwpZLA0a1MFPrC9i6vzbU0/ngCXDjX5OH/opIvt65jF3n7Gn/4MZZqrfiqxYyN0X9rxZcSYPrJH7hQs/qcVdSutoE2PtbAD3Zp0cNBEGY3Wa/t3+vtxq1VtuHhImZLR17Enn6UG+YGecaFOD8qrFsIfiunt+ov1axvPo4YmB/VVL/2CrV1RPTfLEd3zUv0fpU6uxSrzeLEe48ChaNwyUaUKQsRxN7bcrATdg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
t=1664372158; bh=CX0af7D0a63lrpfHnlY0VUsjXQfCKp4HwWglIqLMmXp=;
h=X-Sonic-MF:Date:From:Subject:From:Subject;
b=gTDP4ED6S28n357vXInmaP81UkYE1dT7w4ZYIGVgNNTXWkf81uc5B42jO0UJv+0i2O740ucH8+YGe0SDjsEu8L46wxLU+GeZK2TxJ1o/wkaI/2w/dz66R50b6LS5QupJcZci0ZqllTHtHUimrmbWwzcNOl+go5eJCVJc/Hw+FaD71wX9H5XKbVdi66kwRyG78rmgSLdqdi94fJDcZLyEX34lGXmTvYKOf9MsNeMrEpzRYw+CsadQbu8qJC1XM/Tqr2nc7qnyws34aQlaRs/+Y2gECFEZw+4sh2r/7pS4YICelWkQqqfKwvbjalnuW8unLc7CHZtpXNh4CfoHxM1DJA==
X-YMail-OSG: Etz8NnwVM1kk.2qB5TxaGu.lrFZIIQy2JBQvJRGBvnxYgom8VtE4Ke8V3MYzfwu
nCrg.tmKbgfheOD.nBJaERFuZJft4yoC2ZddoXi3frKh.QryIjN_55PUx.v1Gwnx1PKLoBB.LAZT
35b8bAHSP5Iiu8cpSAUaE00ydi7O3RcufIEuUKd1waDWlnJ5rYVEShDg2PxsfoOllaNZsmYKiPFY
Vr_1plT9AmzFsAipgHcJJp_prO1UTCVxOGLtezSs.JvS_vYRy0KEoNub9eMp1HmVeZCVKkBIGMbE
xISZULTvHmlVE3H443pCo564WfJy42ix7dV1elerj_ZDY1tiMVmo2fai2ihjp1bF.mpFJzQXtFO7
tayGLrtfAKUOVNPCQJ7e1TcYi6m2c4GgMv9vRaKBd6esArS82Tb6AJpsgcmlOtfqzZp0eWhM8i9R
OTNc5vGghvUUhcNDHFC.lSjArWKWbXNjcDOm6O.H3pWUhKhUXcm.SYrSH73ByfuPDYcOnRHpDJ3M
mKzQ0xt7RhxDbCMl02dkR8Acfh9aZ0rt4p.gtz.fBs4pA3MYueQvKpzktV8sj79dD60MmMyFKq1x
T2fcuXTDDIIA3FfvzqE4YedY3x0PFFZcs03PgbG7bO1131AY2FBXl7PksrFDqYJjNxQv3ueyDRfq
wtHuz8S.rlsCabesxgYELgR0htUK3ODIzHQ952IUuMWXcYnSQ9hhAZFvQBPtxV0gfkSLxugtE_qP
A.CANBUPj0Su2CFRolG3pnSqLeggqYkTVwur1N5YrYr0X.a6KBxC3I5LRlwiF95._RdKjAWxV0u8
vFXUcv2oIZczC0jgZyBGvLlQo97zReOg08lm_0HuHZAZVNeUhwf0z6xRnV3DJZMbpXXbmWXJifnO
QtgIiI30hXv2ACngDIkT4Qs7UzxBODoamR2dCOvx26sdJe7Ku5FYjW_K3ZMKF8JBbW0wH8KL.v36
DsxQ8yLpZtX5D8z7JgWa9AYaDcfxSrY9oP4wcjBeZvQQIeCpPq19CY4xbByhCC3uP.l4OU_QYbtJ
nJW3MDMB.tiHKlQDW8tz8PiOE1wqNRzjpZDLCK1bKbfXyzhciiKId3sgNk_HJ8xecUTobyvx4ryS
9.6Vef3mAILpGV.UMr3yAkO65WHpqVE6kj9FyDmDrFnn2mPy.P8S9v0Iw2fENto6PQdORS4G8OST
2lOCo1XY7wBm9i09SQ.X1RbI15Ps9rHNmLZaXBbkYRXRTp2wd1g1LNilmPZShHC4QoRI0eOwzLsT
yLabb.XiT3AOgwvEzev7ETzDZz82fiR0O1frwJE2Zsw4ZPoSdunszVMnldIIFt1zeKlEmeBABfn4
aejpRvcVk.xqk61kGEIZOFDpEbfP_r910T3DAwI2qziVSyWVbRrL1p13OjwgH_CmCmcO8Hubd1Xe
.aaF1HrZ_hdDeSObtCW5W.T.Vie78zScsQCXFlwSfQurHsukQHpjMtKUqaW5VzZ6WeIL4JeDyuus
JKqZ9luH4rP2bZapsC3mE8.VR0FDvwU70kRilANigT8Kf6hfH2i7PvD16b8czzKz2f3H6b561ohp
AsFbZOMvH8bt44h.jihwB.Aw66XsSo2X2ZBQdt_P.sEk9I2KPhEmEwBs.SsW0oMX6jXK5vXbA7IZ
Nluw3n5LUh_veEyyF.YmSX5Ifv.grhq85xaVHz.GM.7RjUKmZIjObK6.QFz4TbZDODwtJEEmggEH
3jGiHg1yw8xcsmzR2lxNg0gvfrCIq6pYtgNXtOP0o1iHIjRvnTVvqVAnrWnFlWTr8kAOOWy_6axu
31b1GCaxNtCqXRwKyexuAu.76AyqByHc3H1LKxv_ZLD3CVxem3IjG8lvWwdMTBz3YLK1XKiPPpws
nYY7EyIbofKfqahR2o9XeAMfeYCwN6g7axHI8RMeuOQERVmvm0GB4nJPvNxLtx27JlAYKmbdNNOZ
mhK6ja1YX.QhKJIqQJCF5xK0f9OQw_pU999rYO95PtKxI7yBQHkWXMSf5KDj6a9WeIBS0kjnLtFt
9Klmf7xbYwFTXmciI_CwJFPjgqfmTSpESkqPPXatr8iI3FshYvrgBFcmj49gFLBPc.xQ7gGQd8v8
4gaKhhIUmWO5n3b3IMGQSvkfk1ongKNyR9teIsIQ.N591W0Ia1yJOOuF_QXX6CNkmDstoYEderZP
PELOZbOM.lfOC8mh5aNY92eBME4ZbnEeLUUj7aOa1S1in3Kmcu7CIsdAS0twRlMkDbL7uje6Awqq
.x5t3Qg5KDZtu9qZ_Nns6tn0fUBVAt86o9fbX1.XD2Frcxtbn8HfaIGIYZkk9
X-Sonic-MF: <lsatenstein@HIDDEN>
Received: from sonic.gate.mail.ne1.yahoo.com by
sonic322.consmr.mail.ne1.yahoo.com with HTTP; Wed, 28 Sep 2022 13:35:58 +0000
Date: Wed, 28 Sep 2022 13:32:50 +0000 (UTC)
From: Leslie S Satenstein <lsatenstein@HIDDEN>
Message-ID: <1442055630.1820916.1664371970607@HIDDEN>
Subject: =?UTF-8?Q?B=C4=B1rthday_Gift?=
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_1820915_2041125903.1664371970605"
References: <1442055630.1820916.1664371970607.ref@HIDDEN>
X-Mailer: WebService/1.1.20702 YMailNorrin
Content-Length: 1889
X-Spam-Score: 4.2 (++++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Hi hope you are safe and good. I want to ask for a discrete
assistance, do you order gifts and items on Amazon? Regards Leslie Leslie
Satenstein Montréal Québec, Canada Hi hope you are safe and good.
Content analysis details: (4.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[66.163.189.60 listed in list.dnswl.org]
1.2 MISSING_HEADERS Missing To: header
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (lsatenstein[at]yahoo.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 HTML_MESSAGE BODY: HTML included in message
1.9 REPLYTO_WITHOUT_TO_CC No description available.
1.0 FREEMAIL_REPLYTO Reply-To/From or Reply-To/body contain
different freemails
X-Debbugs-Envelope-To: 48833
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Leslie S Satenstein <lsatenstein@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Hi hope you are safe and good. I want to ask for a discrete
assistance, do you order gifts and items on Amazon? Regards Leslie Leslie
Satenstein Montréal Québec, Canada Hi hope you are safe and good.
Content analysis details: (2.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[66.163.189.60 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (lsatenstein[at]yahoo.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 HTML_MESSAGE BODY: HTML included in message
1.9 REPLYTO_WITHOUT_TO_CC No description available.
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
------=_Part_1820915_2041125903.1664371970605
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi hope you are safe and good.=C2=A0I want to ask for a discrete assistanc=
e, do you order gifts and items on Amazon?
Regards=C2=A0Leslie
Leslie Satenstein
Montr=C3=A9al Qu=C3=A9bec, Canada
------=_Part_1820915_2041125903.1664371970605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div class=3D"ydp8dd6d64yahoo-style-wrap" style=3D=
"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;">=
<div><div dir=3D"ltr" data-setdir=3D"false"> <div><div dir=3D"ltr" data-set=
dir=3D"false" style=3D"color: rgb(0, 0, 0); font-family: Helvetica Neue, He=
lvetica, Arial, sans-serif;">Hi hope you are safe and good. </div><div=
dir=3D"ltr" data-setdir=3D"false" style=3D"color: rgb(0, 0, 0); font-famil=
y: Helvetica Neue, Helvetica, Arial, sans-serif;">I want to ask for a discr=
ete assistance, do you order gifts and items on Amazon?<br></div><div style=
=3D"color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, san=
s-serif;"><br></div><div class=3D"ydpd5871e25signature" style=3D"color: rgb=
(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><div=
dir=3D"ltr" style=3D"font-family: Helvetica, Arial, sans-serif;"><span lan=
g=3D"FR-CA">Regards</span><div><b><font size=3D"2"> Leslie</font><br><=
/b></div><div><font color=3D"green"><b><font size=3D"1">Leslie Satenstein</=
font></b></font><font size=3D"1" style=3D"color: rgb(191, 0, 95);"><span st=
yle=3D"font-weight: bold;"></span></font><br></div><font color=3D"green"><b=
>Montr=C3=A9al Qu=C3=A9bec, Canada</b></font></div><div><font color=3D"gree=
n"><b><br></b></font></div></div></div><br></div></div></div></body></html>
------=_Part_1820915_2041125903.1664371970605--
bug-coreutils@HIDDEN:bug#48833; Package coreutils.
Full text available.Received: (at 48833) by debbugs.gnu.org; 27 Jun 2021 13:08:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jun 27 09:08:07 2021 Received: from localhost ([127.0.0.1]:49068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1lxUW3-0007qf-DL for submit <at> debbugs.gnu.org; Sun, 27 Jun 2021 09:08:07 -0400 Received: from pio-pvt-msa2.bahnhof.se ([79.136.2.41]:34982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <postmaster@HIDDEN>) id 1lxSSm-0002UF-92 for 48833 <at> debbugs.gnu.org; Sun, 27 Jun 2021 06:56:33 -0400 Received: from localhost (localhost [127.0.0.1]) by pio-pvt-msa2.bahnhof.se (Postfix) with ESMTP id D22BE3F39C; Sun, 27 Jun 2021 12:56:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bahnhof.se X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=6.31 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from pio-pvt-msa2.bahnhof.se ([127.0.0.1]) by localhost (pio-pvt-msa2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2lkU5931y7i; Sun, 27 Jun 2021 12:56:29 +0200 (CEST) Received: by pio-pvt-msa2.bahnhof.se (Postfix) with ESMTPA id AD5183F319; Sun, 27 Jun 2021 12:56:28 +0200 (CEST) Received: from [192.168.0.10] (port=52546) by tnonline.net with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <mail@HIDDEN>) id 1lxSSh-000IY6-Po; Sun, 27 Jun 2021 12:56:27 +0200 Subject: Re: bug#48833: reflink copying does not check/set No_COW attribute and fail To: Zygo Blaxell <ce3g8jdj@HIDDEN>, Paul Eggert <eggert@HIDDEN> References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN> <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN> <20210604201630.GH11733@HIDDEN> <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN> <20210606054242.GI11733@HIDDEN> <4354c814-9f9f-0c26-fb11-36567da6f530@HIDDEN> <20210608024144.GB11713@HIDDEN> From: A L <mail@HIDDEN> Message-ID: <14a60f28-6a74-3315-b756-56ee4b84d583@HIDDEN> Date: Sun, 27 Jun 2021 12:56:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210608024144.GB11713@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 48833 X-Mailman-Approved-At: Sun, 27 Jun 2021 09:07:58 -0400 Cc: 48833 <at> debbugs.gnu.org, linux-btrfs@HIDDEN, Tom Yan <tom.ty89@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 2021-06-08 04:41, Zygo Blaxell wrote: > On Sun, Jun 06, 2021 at 10:47:05PM -0700, Paul Eggert wrote: >> On 6/5/21 10:42 PM, Zygo Blaxell wrote: >>> If cp -a implements the inode attribute propagation (or inheritance), then >>> only users of cp -a are impacted. They are more likely to be aware that >>> they may be creating new files with reduced-integrity storage attributes. >> >> True, although I think this aspect of attribute-copying will typically come >> as a surprise even to "cp -a" users. > > Existing users might be surprised when "cp -a" starts replicating storage > attributes when it did not do so before, but I suspect most future cp > users would expect "cp -a" to preserve storage-policy attributes the same > way it currently preserves ownership, permissions, timestamps, extended > attributes, and security context--a list that initially contained only > the ownership, permissions, and timestamps in the past, the others were > added over time. If not by default, then at least have the ability to > do it when requested with a "--preserve=datacow" switch. ... > The cp doc could be clearer that filesystems that support reflink > don't guarantee every file can be reflinked to every other file. > reflink is expected to fail in a growing number of cases over time, > as more filesystem features are created that are incompatible with it > (e.g. encryption, where reflinks between files with different owners could > be unimplementable). I've seen a number of users get burned by making big > --reflink=always copies and not checking the results for errors, assuming > that only lack of space for metadata could cause a reflink copy to fail. > There are good reasons why --reflink=auto exists and is the default, > and users ignore them at their peril. > Hello everyone, I made a similar thread[1] about a year ago on the coreutils mailing-list and I think it is also relevant to this bug-report. It is true as Zygo mentions, that reflinking nocow and cow files does not work, and cannot work due to the nature of how nocow works. What I would like to add to this bug-report is what elaborated on in the other thread, that we can move forward with preserving all attributes by setting them in the correct order. I show in the message that reflinking works between two nocow files and that ‘cp -a’ could preserve nocow and other attributes if ‘cp -a’ sets those attributes in correct order. As a normal end-user, IMHO, ‘cp -a’ should preserve all attributes where possible, which is also what the manual[2] currently states: ‘--archive’ Preserve as much as possible of the structure and attributes of the original files in the copy (but do not attempt to preserve internal directory structure; i.e., ‘ls -U’ may list the entries in a copied directory in a different order). Try to preserve SELinux security context and extended attributes (xattr), but ignore any failure to do that and print no corresponding diagnostic. Equivalent to -dR --preserve=all with the reduced diagnostics. Only when using --reflink=always, we should fail if the target cannot support reflinks. Thanks! ~A [1] https://lists.gnu.org/archive/html/coreutils/2021-06/msg00005.html that [2] https://www.gnu.org/software/coreutils/manual/html_node/cp-invocation.html#cp-invocation
bug-coreutils@HIDDEN:bug#48833; Package coreutils.
Full text available.Received: (at submit) by debbugs.gnu.org; 27 Jun 2021 13:08:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jun 27 09:08:03 2021 Received: from localhost ([127.0.0.1]:49066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1lxUVz-0007qJ-K5 for submit <at> debbugs.gnu.org; Sun, 27 Jun 2021 09:08:03 -0400 Received: from lists.gnu.org ([209.51.188.17]:42488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <postmaster@HIDDEN>) id 1lxSBn-0008Ky-SV for submit <at> debbugs.gnu.org; Sun, 27 Jun 2021 06:39:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51670) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>) id 1lxSBn-0004jj-L2 for bug-coreutils@HIDDEN; Sun, 27 Jun 2021 06:38:59 -0400 Received: from ste-pvt-msa2.bahnhof.se ([213.80.101.71]:30348) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>) id 1lxSBh-0007r8-9P for bug-coreutils@HIDDEN; Sun, 27 Jun 2021 06:38:58 -0400 Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTP id DF4D03F65E for <bug-coreutils@HIDDEN>; Sun, 27 Jun 2021 12:38:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bahnhof.se X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=6.31 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.202, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from ste-pvt-msa2.bahnhof.se ([127.0.0.1]) by localhost (ste-ftg-msa2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqY9ZH6iTW89 for <bug-coreutils@HIDDEN>; Sun, 27 Jun 2021 12:38:46 +0200 (CEST) Received: by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTPA id E24A73F59B for <bug-coreutils@HIDDEN>; Sun, 27 Jun 2021 12:38:46 +0200 (CEST) Received: from [192.168.0.10] (port=64798) by tnonline.net with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <mail@HIDDEN>) id 1lxSBZ-000HrC-To for bug-coreutils@HIDDEN; Sun, 27 Jun 2021 12:38:46 +0200 Subject: Re: bug#48833: reflink copying does not check/set No_COW attribute and fail To: bug-coreutils@HIDDEN References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN> <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN> <20210604201630.GH11733@HIDDEN> <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN> <20210606054242.GI11733@HIDDEN> <4354c814-9f9f-0c26-fb11-36567da6f530@HIDDEN> <20210608024144.GB11713@HIDDEN> From: A L <mail@HIDDEN> Message-ID: <1ea0660b-f73f-4102-b7f3-8aaf02a6c0dd@HIDDEN> Date: Sun, 27 Jun 2021 12:38:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210608024144.GB11713@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=213.80.101.71; envelope-from=postmaster@HIDDEN; helo=ste-pvt-msa2.bahnhof.se X-Spam_score_int: -23 X-Spam_score: -2.4 X-Spam_bar: -- X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 2021-06-08 04:41, Zygo Blaxell wrote: > On Sun, Jun 06, 2021 at 10:47:05PM -0700, Paul Eggert wrote: >> On 6/5/21 10:42 PM, Zygo Blaxell wrote: >>> If cp -a implements the inode attribute propagati [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 T_SPF_HELO_TEMPERROR SPF: test of HELO record failed (temperror) 0.9 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.org/Why?s=mfrom; id=postmaster%40tnonline.net; ip=209.51.188.17; r=debbugs.gnu.org] -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 27 Jun 2021 09:07:58 -0400 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.9 (---) On 2021-06-08 04:41, Zygo Blaxell wrote: > On Sun, Jun 06, 2021 at 10:47:05PM -0700, Paul Eggert wrote: >> On 6/5/21 10:42 PM, Zygo Blaxell wrote: >>> If cp -a implements the inode attribute propagation (or inheritance), then >>> only users of cp -a are impacted. They are more likely to be aware that >>> they may be creating new files with reduced-integrity storage attributes. >> >> True, although I think this aspect of attribute-copying will typically come >> as a surprise even to "cp -a" users. > > Existing users might be surprised when "cp -a" starts replicating storage > attributes when it did not do so before, but I suspect most future cp > users would expect "cp -a" to preserve storage-policy attributes the same > way it currently preserves ownership, permissions, timestamps, extended > attributes, and security context--a list that initially contained only > the ownership, permissions, and timestamps in the past, the others were > added over time. If not by default, then at least have the ability to > do it when requested with a "--preserve=datacow" switch. ... > The cp doc could be clearer that filesystems that support reflink > don't guarantee every file can be reflinked to every other file. > reflink is expected to fail in a growing number of cases over time, > as more filesystem features are created that are incompatible with it > (e.g. encryption, where reflinks between files with different owners could > be unimplementable). I've seen a number of users get burned by making big > --reflink=always copies and not checking the results for errors, assuming > that only lack of space for metadata could cause a reflink copy to fail. > There are good reasons why --reflink=auto exists and is the default, > and users ignore them at their peril. > Hello everyone, I made a similar thread[1] about a year ago on the coreutils mailing-list and I think it is also relevant to this bug-report. It is true as Zygo mentions, that reflinking nocow and cow files does not work, and cannot work due to the nature of how nocow works. What I would like to add to this bug-report is what elaborated on in the other thread, that we can move forward with preserving all attributes by setting them in the correct order. I show in the message that reflinking works between two nocow files and that ‘cp -a’ could preserve nocow and other attributes if ‘cp -a’ sets those attributes in correct order. As a normal end-user, IMHO, ‘cp -a’ should preserve all attributes where possible, which is also what the manual[2] currently states: ‘--archive’ Preserve as much as possible of the structure and attributes of the original files in the copy (but do not attempt to preserve internal directory structure; i.e., ‘ls -U’ may list the entries in a copied directory in a different order). Try to preserve SELinux security context and extended attributes (xattr), but ignore any failure to do that and print no corresponding diagnostic. Equivalent to -dR --preserve=all with the reduced diagnostics. Only when using --reflink=always, we should fail if the target cannot support reflinks. Thanks! ~A [1] https://lists.gnu.org/archive/html/coreutils/2021-06/msg00005.html that [2] https://www.gnu.org/software/coreutils/manual/html_node/cp-invocation.html#cp-invocation
bug-coreutils@HIDDEN:bug#48833; Package coreutils.
Full text available.Received: (at 48833) by debbugs.gnu.org; 8 Jun 2021 02:54:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 07 22:54:41 2021 Received: from localhost ([127.0.0.1]:57161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1lqRt3-00033Y-66 for submit <at> debbugs.gnu.org; Mon, 07 Jun 2021 22:54:41 -0400 Received: from james.kirk.hungrycats.org ([174.142.39.145]:33106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <postmaster@HIDDEN>) id 1lqRgX-0002lc-WF for 48833 <at> debbugs.gnu.org; Mon, 07 Jun 2021 22:41:46 -0400 Received: by james.kirk.hungrycats.org (Postfix, from userid 1002) id 244ABA92DA4; Mon, 7 Jun 2021 22:41:44 -0400 (EDT) Date: Mon, 7 Jun 2021 22:41:44 -0400 From: Zygo Blaxell <ce3g8jdj@HIDDEN> To: Paul Eggert <eggert@HIDDEN> Subject: Re: bug#48833: reflink copying does not check/set No_COW attribute and fail Message-ID: <20210608024144.GB11713@HIDDEN> References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN> <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN> <20210604201630.GH11733@HIDDEN> <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN> <20210606054242.GI11733@HIDDEN> <4354c814-9f9f-0c26-fb11-36567da6f530@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4354c814-9f9f-0c26-fb11-36567da6f530@HIDDEN> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 48833 X-Mailman-Approved-At: Mon, 07 Jun 2021 22:54:40 -0400 Cc: 48833 <at> debbugs.gnu.org, linux-btrfs@HIDDEN, Tom Yan <tom.ty89@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.8 (/) On Sun, Jun 06, 2021 at 10:47:05PM -0700, Paul Eggert wrote: > On 6/5/21 10:42 PM, Zygo Blaxell wrote: > > If cp -a implements the inode attribute propagation (or inheritance), then > > only users of cp -a are impacted. They are more likely to be aware that > > they may be creating new files with reduced-integrity storage attributes. > > True, although I think this aspect of attribute-copying will typically come > as a surprise even to "cp -a" users. Existing users might be surprised when "cp -a" starts replicating storage attributes when it did not do so before, but I suspect most future cp users would expect "cp -a" to preserve storage-policy attributes the same way it currently preserves ownership, permissions, timestamps, extended attributes, and security context--a list that initially contained only the ownership, permissions, and timestamps in the past, the others were added over time. If not by default, then at least have the ability to do it when requested with a "--preserve=datacow" switch. We could say "cp --reflink=always implies --preserve=datacow because it might not work otherwise", which solves the immediate issue as presented, but I don't think we _want_ to say that because it has a potentially bad surprising case when attribute changes are unexpected (it's the same reason that we would not want to implement it that way in the kernel). As a cp user, I would prefer to make the choice to copy the storage attributes with --preserve or -a, and after that choice is made, then --reflink=always will work because cp is setting attributes in dst to match src as I requested it to do. If I had made the opposite choice (didn't use -a or --preserve, or did use --no-preserve=datacow), then cp shall not copy the storage attributes, the dst inodes have attributes inherited from dst's parent, --reflink=always fails when there are mismatches as it does now, and --reflink=auto or =none copies may have different storage attributes from the src (with possibly stronger or weaker integrity). We could say "'cp -a --reflink=always' implies --preserve=datacow, but '--reflink=always' and '-a' by themselves do not." It seems complex to describe, but maybe it does surprise the fewest people in the most beneficial way: plain 'cp -a' users keep exactly the old behavior, while 'cp -a --reflink=always' users get successful copies in one case where they currently get unexpected failures. 'cp -r' doesn't imply --preserve=all, so 'cp -r --reflink=always' would need to be accompanied by '--preserve=datacow' or '--preserve=all' to get the attribute-copying. The cp doc could be clearer that filesystems that support reflink don't guarantee every file can be reflinked to every other file. reflink is expected to fail in a growing number of cases over time, as more filesystem features are created that are incompatible with it (e.g. encryption, where reflinks between files with different owners could be unimplementable). I've seen a number of users get burned by making big --reflink=always copies and not checking the results for errors, assuming that only lack of space for metadata could cause a reflink copy to fail. There are good reasons why --reflink=auto exists and is the default, and users ignore them at their peril. The really awful thing about all this is that it's not datacow, the thing visible with chattr +/-C and implemented by other filesystems, that is the problem. The problem is the datasum bit hidden behind the datacow bit on btrfs. datasum can still be disabled even when datacow is enabled, and datasum requires privileges to detect (unprivileged users can only observe the datasum bit's effect on reflink copies to files with the opposite datasum setting). The proper option name should be --preserve=datasum, but cp can only examine or change the datacow bit. > > If the file is empty, you can chattr +C or -C. If the file is not > > empty, chattr fails with an error. > > Although coreutils 'cp -a' currently truncates any already-existing output > file (by opening it with O_TRUNC), it then calls copy_file_range before > calling fsetxattr on the destination. Presumably cp should do the equivalent > of chattr +C before doing the copy_file_range stuff. (Perhaps you've already > mentioned this point; if so, my apologies for the duplication.) The important thing is that got across, whether you extracted it from what I wrote, or reconstructed it from context.
bug-coreutils@HIDDEN:bug#48833; Package coreutils.
Full text available.Received: (at 48833) by debbugs.gnu.org; 7 Jun 2021 05:47:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 07 01:47:17 2021 Received: from localhost ([127.0.0.1]:54307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1lq86X-0006Uh-BN for submit <at> debbugs.gnu.org; Mon, 07 Jun 2021 01:47:17 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:59658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eggert@HIDDEN>) id 1lq86T-0006UO-Ta for 48833 <at> debbugs.gnu.org; Mon, 07 Jun 2021 01:47:16 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BBC7516005E; Sun, 6 Jun 2021 22:47:07 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 94233WHieqS7; Sun, 6 Jun 2021 22:47:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1200C160064; Sun, 6 Jun 2021 22:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rU0UWHVL2jpA; Sun, 6 Jun 2021 22:47:06 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D5E9116005E; Sun, 6 Jun 2021 22:47:06 -0700 (PDT) To: Zygo Blaxell <ce3g8jdj@HIDDEN>, Tom Yan <tom.ty89@HIDDEN> References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN> <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN> <20210604201630.GH11733@HIDDEN> <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN> <20210606054242.GI11733@HIDDEN> From: Paul Eggert <eggert@HIDDEN> Organization: UCLA Computer Science Department Subject: Re: bug#48833: reflink copying does not check/set No_COW attribute and fail Message-ID: <4354c814-9f9f-0c26-fb11-36567da6f530@HIDDEN> Date: Sun, 6 Jun 2021 22:47:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210606054242.GI11733@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48833 Cc: 48833 <at> debbugs.gnu.org, linux-btrfs@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 6/5/21 10:42 PM, Zygo Blaxell wrote: > If cp -a implements the inode attribute propagation (or inheritance), t= hen > only users of cp -a are impacted. They are more likely to be aware tha= t > they may be creating new files with reduced-integrity storage attribute= s. True, although I think this aspect of attribute-copying will typically=20 come as a surprise even to "cp -a" users. > If the file is empty, you can chattr +C or -C. If the file is not > empty, chattr fails with an error. Although coreutils 'cp -a' currently truncates any already-existing=20 output file (by opening it with O_TRUNC), it then calls copy_file_range=20 before calling fsetxattr on the destination. Presumably cp should do the=20 equivalent of chattr +C before doing the copy_file_range stuff. (Perhaps=20 you've already mentioned this point; if so, my apologies for the=20 duplication.)
bug-coreutils@HIDDEN:bug#48833; Package coreutils.
Full text available.
Received: (at 48833) by debbugs.gnu.org; 7 Jun 2021 02:01:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jun 06 22:01:11 2021
Received: from localhost ([127.0.0.1]:54213 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1lq4Zf-0000QL-Os
for submit <at> debbugs.gnu.org; Sun, 06 Jun 2021 22:01:11 -0400
Received: from sonic304-22.consmr.mail.ne1.yahoo.com ([66.163.191.148]:36783)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <lsatenstein@HIDDEN>) id 1lq4ZZ-0000Pf-HZ
for 48833 <at> debbugs.gnu.org; Sun, 06 Jun 2021 22:01:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
t=1623031255; bh=wgOfJuvF88WLGFigTscT7GQtd70+YFzpKdIsec+RsSk=;
h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To;
b=nX17cY3UG51A58e8oTPQtgHqgJUZdmXuNrAXLbMzgHgSVUd+gjBllknnHzfaDdYOQ3XrRxR2OM+ewKXXxjeGeP2OwIKdUFqq8iCCOZMQeQgXm6ePuOZNSuETZyy19Rgnd5tTglAMXU7BAJ5acEqSDxNPdG3iDx3vuX1agPnT6+/NrzWfXbAsunIekci+h3pK1tXTFAqZAApQIcQgSrwTHF/wiCR/VnosReissWJpl02a++S/WMUOZlZnw9jeRwxRwMVMT7ST1Csf1bMD+0QnDVI50hbtD4i+VF38LGDyqbmrSDe0FCN9O3Pyi2KGJtvFG8J1XZDdpisAJr4xA06g1g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
t=1623031255; bh=3KB8fP6LQSfmy5NQ62whqY+8hCYHKigm5Z7JWAfFkfX=;
h=X-Sonic-MF:Date:From:To:Subject:From:Subject;
b=jMeURQlBdmC/OprJbPDtep4NR0lbEwpisXtXSsKs83X0DUv5phNe1CDfUb6l8BGtu1FQ1/+GQcllZAIOCVdrroDiDB1TFkDV0ZPsjn0qLksURStYp93gktn+dL9M1sy0GCXZUgXo7700OWv+ZkIpkkwaCfWRKt8qNVQzuhI6Kaz3jO3i1GhcveCQRO9EgriPmtY5H5Y1Ppcxt/T65WOtJMIpk2MwQCuabkR2HRNoWmCiAH9DGczcfaUIpfBIHaA5cTKaikqNCZ0KIs4Zc36BfIX9EQd5CMt/crsOHXohFhCZaQGVHvEQ0OfqWtyFZAsYyLtplwcyXtnST2dpotjMTg==
X-YMail-OSG: 8YKMmDEVM1mKlY.Akhx71FGvUia1FruE8OADVcUUWqTO7WiDUAvw0BFyVnyYqJ5
eSDt7em3mIJkRboE99jFSpoex1GgxqrCh8MG87U9kXozC1qPkzxE0YRg8kuU6DM33u2eKR6Uh5B2
awAOaDZxzGd.HaCJJolP6yQlYfIRuEDZbfCxRnUfA78Ci0ajIWcqmwUjlEwuTh4pvYCM_oU75EzK
S5o4O3Gxk4IDh7c4oMrZtLCGeCui_.L9ErSUTZ3NqykOhXqjqBFWL9QI8E8doa2n047izGZXPXU2
g91MFi_f4DS5RPBgavvdRDYbjGcORW0jvumzqmFONoZdY04IWtQqYWaNMvJHwYOc.fixC48QhxWf
5Jupyvwg4OzcSpOvk8PYCJTcv4QFXfyNLXbOhuxmRQPMezszdcVOsJi3NhRtCx0DXQPIxX0AJ_Un
A3DfcFd.D1omitKcS_qIbgfz06Kos.V4V03Yj9kjLzEwmw_Ihc8e46m.8_hK8MHipVJzTL_Vqf93
3Ueikf6ulV3n73CinuDPNVeHQ6I_7gCi0DjtpNmnXT82JvGwT33D6O94Brr16jb6nM6hZyNLKB5I
BoHR_DLMtHV7DFcSx0ZHgurcB3ZEWBIhCGJgHIKgI_3qC9MOK10zdRi5qxMuUCTBHhagelZ6m9Xp
UzOEu0_oiev9FzsjCnAYCzxDSZDSVlU_LCfayTm82zeqHQ0On5qVfeBh3xpFsliAXr4JDr2FarYn
TAboUyiP80Ci0UaBsjIio6IxOfdP8aEZ3eIzNXKalbMMTRUbe6jatHgWHGjl1_80XGdcEjgKTyDi
O1mh4WPpn079OuhqKTwGXeodXbrtQrw6t2KNUUD_W9gMM.Q0tz4agAdfIrxpHy2ua5uA2CBweH9T
zIOXn9fCYkTd_DIN7YgwQHktr4nxV1yQt972b7AITeKOeBonlOyHBf2rvu8x9e0ShRP8aeAj_48n
JRHwHOPYzZNrtCL8uvV6NnqutGtHNx6PMd9PXxZBNCV_JfCPBw8xQw5ZqmeNJ5P8dlYoyo7Gf5WP
QQJ1JuZ39eFVWY41Sx33G.e4zCTt8RdeQAx3kpJlooz0dgBgTiP6HSfyvEQgWjnmDP0EOSuKeeJK
DX5ttL___YDEd2z53NxPa8Hor60y.M8O869TRcbXLJ4ELkgE0EjAxkxJZ7XTiv07smahlfqaxouv
q_omqjPfwea384biQ5QaUouaId5xWcItb9KafGfqu8G88FjvkY6dwtMEytUO_SJrVzRcgvZnuemE
GaGpCN8al4t016ne8Ii2Mx4bWp8uqymewASQFIgiC.v3ThR0SjmLnwbhYAScJmCGDs1TmqsjRHHy
_oFtPTZjV39tflr1EBB1k2dA73dmVb_EZdeYPqFNzg03MNDInQJ.P7YvxCiooBNtTd.atf1qUapU
CyHwhd3_HFRGzSQBgmjfGQ6_UaChgSTxLxd4nXJrS7BQYIGN6.ld_oW2Cgd2VdbEYzRI7D3M.JqR
j05LPkLWdx3ALnERr7TmL0yVbaLrL.PfKyx7iVkWdYkNI73FTmNIy48Xbcai0DrSj8Uy4_nkAiNx
5oU3NzqHClPcXZOPfeT6Gvd477k3pqzGOhmfafakBJYuAtWYj8B7VNBJRGxgLxJIU.dj4vt1R8VY
N70HZH3Vhqwm_Lc4WFt2kD2GLU2.jKiVla7RNEd3SnhO4zlzPb6AfpiY.iwg4mzjtzx6mJOxZvrK
Sbo039y65PI9FGlI9jcWsigsUJTH5V3oVIUPbM6wp_HMZ6mhGznFlkURDCXM6A7EtGL4xnlqIOJ8
EGZDMIgAdB7xp5CneeuGSoOv0myvYP6CAJ4DwZnDDuK8O9DeGZCEeWklcjODEcE7J5GG8Ui6nh_f
m3447CZxwkhOod4ZmuLHwl82MyYegGPRPi5McfBCSv.8SvLKEQlSq7O6iAMSjDQ3Pvrt_fET8Oup
eL0Q93ZZwxC1ThQTVYEKQvhMC85VlCkS0Pt5NI5DObhuS5Oy3cm4zrb7y3qGA5nXEXwWFozSEn8H
SNs0BdQeuPenBr5OGV7dWl8H4NceaPQJaFHc00slQHcuh_GFS1QhxW3vk1O17fYSIefMvmQ2DgGK
vxB5tMspqwZWwhDiNybvdolJGqBMg0bbKU8XdX60ql7Uz9xT4SNjMf3e960m1duB6n3jNgqAaC2k
pz2x8q3nYgQjd9hnLXFfC7OIzQug3dYhiMy8O6zROG7PGVsuVUlfnIDmi.V_dsj1kY2QLkjvorcQ
uGUrOscTeJrDe2Dregwv6Unhfp7Hl1TsZ1boDx1O.E9YRhDYu0AqKLfS11ZY7VB_HVGQpDooMpEn
N.fj5lrrN2dsWtRMLNb2.4q6Lsj0uVMcsyqGD6ZDwrqg8jkUEuGuyY1m9lK_2rwiQN8yd_O_6EsU
94XQsx7HuMuYxnH0woo55vHMbpgUT_UWVnUo2WM0XyK9aNw0cDTIc_H.gvCqksBelVWBTErm0.C4
i1TtRtWhRnaqxLUaHqoByVg5eYWvkWtaCNbKlyn6OfWuM8pboXB2KCvpa8OC.it2o34u.39g1o3D
kJxnVIx7Ir0t0jPpAQnWX4D.BM8LpgYzS4GczL.95HPjpXRsWJlWTW0JKYLC4mze0wUF_Wd_6kXG
AOqlxJ7Q7162hFOpzdtshW_cL_jkqtLVkbI6gWDrcDjw738NTbHTFXqrPGb1hfWwXSMVtU3no4dP
hCyRzqgCRwJQ2T7Y.0Lo0zTdAFzFCwbRnDb0QxYXNVMFXQ9uciuTGbbsU.2dOmcA156M3AUAWn_1
TqvkWyA--
X-Sonic-MF: <lsatenstein@HIDDEN>
Received: from sonic.gate.mail.ne1.yahoo.com by
sonic304.consmr.mail.ne1.yahoo.com with HTTP; Mon, 7 Jun 2021 02:00:55 +0000
Date: Mon, 7 Jun 2021 02:00:52 +0000 (UTC)
From: Leslie S Satenstein <lsatenstein@HIDDEN>
To: Tom Yan <tom.ty89@HIDDEN>,
Zygo Blaxell <ce3g8jdj@HIDDEN>
Message-ID: <39466090.4286189.1623031252971@HIDDEN>
In-Reply-To: <20210606054242.GI11733@HIDDEN>
References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN>
<CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
<20210604201630.GH11733@HIDDEN>
<CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN>
<20210606054242.GI11733@HIDDEN>
Subject: Re: bug#48833: reflink copying does not check/set No_COW attribute
and fail
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_4286188_894301194.1623031252967"
X-Mailer: WebService/1.1.18368 YMailNorrin
Content-Length: 43205
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 48833
Cc: "48833 <at> debbugs.gnu.org" <48833 <at> debbugs.gnu.org>,
"linux-btrfs@HIDDEN" <linux-btrfs@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Leslie S Satenstein <lsatenstein@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
------=_Part_4286188_894301194.1623031252967
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I believe that /etc/fstab should not be subject to COW.=C2=A0 We can have p=
artitions dynamically mounted by users=20
(noauto,user on the fstab line).
/boot/efi must be protected as well.=C2=A0 Sometimes this directory is redi=
rected.=C2=A0 I have experienced cow issues with system reboots.=C2=A0 Then=
running btrfs to defrag , the system can be rebooted.
Regards=20
=C2=A0Leslie
Leslie Satenstein
Montr=C3=A9al Qu=C3=A9bec, Canada
=20
On Sunday, June 6, 2021, 4:43:44 a.m. EDT, Zygo Blaxell <ce3g8jdj@umail=
.furryterror.org> wrote: =20
=20
On Sat, Jun 05, 2021 at 01:56:49PM +0800, Tom Yan wrote:
> As far as I'm concerned, inheriting an attribute from the source inode
> isn't a "surprising" behavior. Rather it seems pretty "natural" to me.
> And I don't think whether the attribute is "dangerous" changes that,
> because if you consider it "dangerous", shouldn't you "watch out"
> anyway when you try to make a clone of a source with such an
> attribute?
It's important not to conflate the two contexts.=C2=A0 For cp -a, copying
attributes from the src inode might be obvious.=C2=A0 For any other applica=
tion
(including cp with different arguments), it might be the worst possible
thing to do, especially if we've been doing the opposite for over
a decade.
People run btrfs on crappy SSD and MMC devices, where filesystem csums
are the only way to know the disk is failing (SMART is nonexistent,
and the firmware doesn't bother with any form of working ECC or CRC, so
the first indication of any drive failure is when it starts corrupting
data).=C2=A0 Disabling the datasum bit on any inode is eventually equivalen=
t
to injecting a stream of random undetected corruption into the file when
the drive inevitably fails.=C2=A0 For users with such drives, a mount optio=
n
or filesystem feature flag to disable chattr +C globally would make sense,
as they never want any file to be nodatasum for any reason.
If cp -a implements the inode attribute propagation (or inheritance), then
only users of cp -a are impacted.=C2=A0 They are more likely to be aware th=
at
they may be creating new files with reduced-integrity storage attributes.
> If we see it from the way that, the kernel does not make the
> destination inherit nodatasum just to make reflink succeed as much as
> possible, but rather it just by design inherit nodatacow (for the
> reason of being NOT surprising), then there's no concern in whether
> they should "decoupled" when we implement the inheritance. (Like we
> can't set only nodatasum with `chattr either. It's simply out of the
> scope then.)
Thw window for design of these features mostly closed in 2008.=C2=A0 If we
limit the scope as you suggest, we stuck with a lot of the current
behavior now because it is existing kernel API.
If we also fixed some of the other design issues, like the invisible
datasum attribute, we could make the case that at least these automatic
implied inode changes would be _visible to users_.=C2=A0 At the moment,
it requires special tools to inspect the filesystem to see that a file
has its nodatasum bit set, and we probably don't want to start silently
flipping any more inode bits users can't even see.=C2=A0 We already did tha=
t
with prealloc and no-compression attributes, and users find it difficult
to understand the resulting changes in btrfs behavior.=C2=A0 There are some
proposals in the works to make all the inode flags visible as xattr
properties, and if those are done then we can say "well at least you
can see that we now change the datasum attribute sometimes."=C2=A0 But it's
a very weak argument.
The kernel has no way to know it's running 'cp -a' or that the intent
is to copy an existing object.=C2=A0 A user could be constructing a new
object using a combination of writes and reflinks from other files
(e.g. a disk image compiler) and intend for the result to have csums
even if the reflinked source files did not.
The kernel only knows that it has been told to create a file with XZ
attributes, and later the user requests cloning data from a file with
XYZ attributes.=C2=A0 If the user didn't intend for the dst file to have
XYZ attributes (and why would she, when she created the file with XZ
attributes?), then it could be a serious regression if the file suddenly
ends up with unintended Y attributes on new kernels.=C2=A0 Without easy
userspace visibility of the nodatasum attribute, it would be difficult
to even _detect_ this change until after silent data corruption gets
bad enough to be noticed.
Contrast with the coreutils package, which has changed its behavior
several times since reflink was first introduced in 2009 to adapt to
changing user expectations.=C2=A0 Nobody expects coreutils to behave quite
the same way from one year to the next, so there is room for innovation
there--and users who don't want the innovations can fork coreutils or
use some other tools.=C2=A0 One such innovation could be to simply detect
this case and make the appropriate inode changes before copying.
On the other hand, maybe nobody has any existing software deployed that
depends on the old kernel behavior, so we can change it after all.=C2=A0 In=
the
dangerous case (cheap SSD), a sysadmin wouldn't have any nodatacow files
anywhere on the filesystem, so they wouldn't be making reflink copies
of them because none exist.=C2=A0 They could be making a copy of a nodataco=
w
file from another filesystem, but in that case they would be using normal
copy, since reflink doesn't work across filesystems.=C2=A0 Maybe we can fin=
d
all the users who are running reflinking disk image compilers and they
can update their code to work around the proposed new kernel behavior.
> I don't know if we can do that based on whether the reflink mode is
> always. Though we can fallback to "normal" copy when the source has
> nodatasum (and/or nodatacow), personally I don't find it less
> surprising than inheriting nodatacow all the time.
Note that the kernel never sees the reflink argument from cp.=C2=A0 It is
entirely implemented inside the 'cp' command.=C2=A0 In --reflink=3Dauto mod=
e,
cp will first try clone_range, and if the kernel rejects that with an
EINVAL error, then cp will try again with traditional read/write code.
This is after cp has already created the dst file.=C2=A0 The kernel does
not provide a "create a new file with the attributes of an old file"
call--cp has to create the file with open(), and then do a series of
chmod, chown, and setfattr calls in the right order to replicate the
attributes of the old file.
The kernel doesn't guarantee that reflinks are possible in all cases, and
generally does not provide any fallback.=C2=A0 There are multiple possible
responses to a reflink failure and the kernel cannot implement all
of them.=C2=A0 It is up to userspace (i.e. the cp command) to decide what a
correct fallback behavior should be, and then implement it.
> By the way, what will `chattr -C` do exactly if the file/inode had
> nodatacow? Is the behavior different when it is / there is a reflink?
If the file is empty, you can chattr +C or -C.=C2=A0 If the file is not
empty, chattr fails with an error.
All the data extents in a file have to have the same csum status (csum
present or csum absent) as the inode.=C2=A0 It is not allowed to change the
C attribute when data extents exist because the C attribute indirectly
affects whether the extents have data csums or not, and if the inode was
changed it would disagree with existing data extents.=C2=A0 If no data exte=
nts
exist (i.e. zero-length file), then the inode attribute can be changed,
because there is nothing present that could disagree with the inode.
It doesn't matter whether reflinks were previously made or not.=C2=A0 In bt=
rfs
there is no difference between a reflink and any other write, in the
same way that there is no difference between a directory entry created
by hardlink versus any other file creation.=C2=A0 Normal writes create a
new data extent, then reflink it to exactly the spot in file where the
data was written.=C2=A0 clone_range creates a reflink to some data extent(s=
)
that already exist.=C2=A0 Like hardlinks, when a reflink copy is made, it i=
s
not always possible to tell which was the original and which was the copy.
> On Sat, 5 Jun 2021 at 04:16, Zygo Blaxell
> <ce3g8jdj@HIDDEN> wrote:
> >
> > On Fri, Jun 04, 2021 at 10:37:35PM +0800, Tom Yan wrote:
> > > Also cc'ing bug-coreutils@HIDDEN
> > >
> > > On Fri, 4 Jun 2021 at 22:33, Tom Yan <tom.ty89@HIDDEN> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I've just bumped into a problem that I am not sure what the expecte=
d
> > > > behavior should be, but there seems to be something flawed.
> > > >
> > > > Say I have a file that was created with the No_COW attributed
> > > > (inherited from the directory / subvolume / mount option). Then if =
I
> > > > try to do a reflink copy, the copying will fail with "Invalid
> > > > argument" if the copy has no one to inherit the No_COW attribute fr=
om.
> >
> > Correct.=C2=A0 nodatacow implies nodatasum, and you cannot reflink an e=
xtent
> > from a nodatasum inode into a datasum inode.
> >
> > The result of allowing this would be a file that has some extents
> > that have csums, and some that do not.=C2=A0 Making this work would mak=
e
> > reading from such a file worse (i.e. make it slower, or fail to detect
> > corruption in metadata).=C2=A0 It's possible to solve some of those pro=
blems
> > (or at least contain them in inodes that are known to have mixed csum
> > and non-csum data), but first someone would have to make the case that
> > this is worth the effort to support.
> >
> > > > For example:
> > > > [tom@archlinux mnt]$ sudo btrfs subvol list .
> > > > ID 256 gen 11 top level 5 path a
> > > > ID 257 gen 9 top level 5 path b
> > > > [tom@archlinux mnt]$ lsattr
> > > > ---------------------- ./a
> > > > ---------------C------ ./b
> > > > [tom@archlinux mnt]$ lsattr b/
> > > > ---------------C------ b/test
> > > > [tom@archlinux mnt]$ du -h b/test
> > > > 512M=C2=A0 =C2=A0 b/test
> > > > [tom@archlinux mnt]$ lsattr a/
> > > > [tom@archlinux mnt]$ cp --reflink=3Dalways b/test a/
> > > > cp: failed to clone 'a/test' from 'b/test': Invalid argument
> > > > [tom@archlinux mnt]$ lsattr a/
> > > > ---------------------- a/test
> > > > [tom@archlinux mnt]$ du a/test
> > > > 0=C2=A0 =C2=A0 a/test
> > > > [tom@archlinux mnt]$ du --apparent-size a/test
> > > > 0=C2=A0 =C2=A0 a/test
> > > > [tom@archlinux mnt]$ rm a/test
> > > > [tom@archlinux mnt]$ sudo chattr +C a/
> > > > [tom@archlinux mnt]$ cp --reflink=3Dalways b/test a/
> > > > [tom@archlinux mnt]$ lsattr a/
> > > > ---------------C------ a/test
> > > > [tom@archlinux mnt]$ cmp b/test a/test
> > > > [tom@archlinux mnt]$
> > > >
> > > > I'm not entirely sure if a reflink copy is supposed to work for a
> > > > source file that was created with No_COW, but apparently it is.
> >
> > Snapshots are also allowed for nodatacow files.=C2=A0 The extents that =
are
> > shared become implicitly datacow until they are not shared any more.
> >
> > Snapshots are deferred reflink copies, so it would be difficult to
> > allow one and not the other.=C2=A0 Disallowing both seems overly restri=
ctive
> > (e.g. with such a restriction, it would not be possible to use 'btrfs
> > send' or make a snapshot on a subvol that contains any nodatacow file).
> >
> > btrfs did disallow both operations for swap files, so it could be possi=
ble
> > to disallow both reflinks and snapshots for nodatacow files, but AFAIK
> > nobody wants that (some people even want the swapfile restrictions to
> > go away someday).
> >
> > > > The
> > > > problem is just that the reflink copy also needs to have the attrib=
ute
> > > > set, yet it cannot inherit from the source automatically.
> >
> > reflink can only reflink copy from one nodatasum file to another nodata=
sum
> > file, or from one datasum file to another datasum file.
> >
> > An empty inode can be changed from datacow to nodatacow (or vice versa)
> > using the fsattr ioctl, which simultaneously changes the file from
> > datasum to nodatasum if the filesystem was not mounted with the nodatas=
um
> > mount option.
> >
> > There is a possible kernel enhancement here:=C2=A0 when an empty inode =
is the
> > dst of a reflink, automatically change the reflink dst inode's nodatasu=
m
> > flag to match the reflink src inode's nodatasum flag.=C2=A0 If the dst =
inode
> > is not empty and the inode datasum flags do not match, then reject the
> > reflink with EINVAL as before.
> >
> > It's not clear whether this should apply only to nodatasum or also to
> > nodatacow.=C2=A0 reflink doesn't need src and dst agreement on nodataco=
w,
> > so the dst inode could be a nodatasum+datacow file.=C2=A0 Unfortunately=
all
> > the userspace tools including coreutils can only see the nodatacow
> > inode bit, not the nodatasum bit, so the lack of csums on the dst file
> > would be invisible.=C2=A0 The kernel cannot know the user's intent from=
the
> > available information.
> >
> > It's not clear that we want the kernel to be implicitly changing
> > inode attribute bits like this--especially bits that disable integrity
> > features like nodatasum.=C2=A0 There is precedent for changing fsattrs =
with
> > the no-compress inode flag, but that flag doesn't disable csums, and
> > this one would.
> >
> > One could also make the opposite case:=C2=A0 it should always be an err=
or to
> > do anything that would put data in a datasum file without csums, the
> > existing behavior is correct, and should not be changed.=C2=A0 The prob=
lem
> > with this argument is that users can't see the datasum inode bits,
> > so it's not clear that the EINVAL is a data protection mechanism.
> >
> > > > I wonder if this is a kernel-side problem or something that coreuti=
ls
> > > > missed? It also seems wrong that when it fails there will be an emp=
ty
> > > > destination file created.
> >
> > Normally coreutils will fall back to simple copy if --reflink=3Dauto
> > is used.=C2=A0 --reflink=3Dalways is the user's explicit request for "r=
eflink
> > or nothing, please."=C2=A0 The user correctly got nothing, as requested=
.
> >
> > On other filesystems, reflink on a nodatacow file might make a simple
> > copy in the kernel--in which case you are no better off than if you had
> > used --reflink=3Dauto.
> >
> > coreutils could propagate the source inode nodatacow fsattribute to
> > the destination inode if it intends to use reflink to copy the data.
> > That would be the userspace equivalent of the kernel enhancement I
> > suggested above.=C2=A0 It would probably match user expectations better=
--no
> > hidden surprises for non-coreutils use cases, and all the affected inod=
e
> > attribute bits are necessarily visible in userspace.
> >
> > fsattr propagation could be quite complicated for coreutils to implemen=
t
> > correctly in general, as some fsattrs should not be propagated this way=
,
> > and other filesystems may have different restrictions.=C2=A0 Some fsatt=
rs must
> > be set before the data is written (e.g. -c for compression), others mus=
t
> > be set after the data is written (e.g. -i for immutable), and some are
> > a matter of user intent (e.g. should a simple copy be compressed if the
> > source is not?=C2=A0 Depends on the intended use of the copy).
> >
> > On other filesystems this userspace behavior might trigger the opposite
> > of the intended kernel behavior, causing reflink to always fall back to
> > simple copy because the dst inode's nodatacow attribute is set.
> >
> > Ideally btrfs will not force coreutils to do one thing on btrfs and the
> > opposite thing on other filesystems, so it might be worthwhile to hack
> > around this in the kernel as proposed above.=C2=A0 There is precedent f=
or
> > that--btrfs falls back to simple copy in reflinks of inline extents,
> > more or less for the sole purpose of making cp --reflink=3Dalways not f=
ail
> > so randomly.
> >
> > > > Kernel version: Linux archlinux 5.12.8-arch1-1 #1 SMP PREEMPT Fri, =
28
> > > > May 2021 15:10:20 +0000 x86_64 GNU/Linux
> > > > Coreutils version: 8.32
> > > >
> > > > Regards,
> > > > Tom
=20
------=_Part_4286188_894301194.1623031252967
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div class=3D"ydpe2616bf0yahoo-style-wrap" style=
=3D"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px=
;"><div><div dir=3D"ltr" data-setdir=3D"false">I believe that /etc/fstab sh=
ould not be subject to COW. We can have partitions dynamically mounte=
d by users <br></div><div dir=3D"ltr" data-setdir=3D"false">(noauto,user on=
the fstab line).</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><di=
v dir=3D"ltr" data-setdir=3D"false">/boot/efi must be protected as well.&nb=
sp; Sometimes this directory is redirected. I have experienced cow is=
sues with system reboots. Then running btrfs to defrag , the system c=
an be rebooted.</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div =
dir=3D"ltr" data-setdir=3D"false"><br></div><div><br></div><div class=3D"yd=
pe2616bf0signature"><div><div><div><div><div><div><div><span lang=3D"FR-CA"=
>Regards</span> <div><b><font size=3D"2"><br></font><font size=3D"2"> =
;Leslie</font><br></b></div> <div><font color=3D"green"><b><font size=3D"1"=
>Leslie Satenstein</font></b></font><font style=3D"color:rgb(191, 0, 95);" =
size=3D"1" color=3D"green"><span style=3D"font-weight:bold;"></span></font>=
<br></div><font size=3D"2" color=3D"green"><b>Montr=C3=A9al Qu=C3=A9bec, Ca=
nada</b><br></font><br><font size=3D"1" face=3D"lucida console, sans-serif"=
><b id=3D"ydpe2616bf0yui_3_13_0_ym1_1_1391351152837_28311"><font id=3D"ydpe=
2616bf0yui_3_13_0_ym1_1_1391351152837_28310" color=3D"black"><span id=3D"yd=
pe2616bf0yui_3_13_0_ym1_1_1391351152837_28309" style=3D"font-weight:bold;fo=
nt-size:13.5pt;color:black;"></span></font></b></font></div></div></div></d=
iv></div></div></div></div></div>
<div><br></div><div><br></div>
=20
</div><div id=3D"ydpc369ab51yahoo_quoted_3575257451" class=3D"ydpc3=
69ab51yahoo_quoted">
<div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
=20
<div>
On Sunday, June 6, 2021, 4:43:44 a.m. EDT, Zygo Blaxell=
<ce3g8jdj@HIDDEN> wrote:
</div>
<div><br></div>
<div><br></div>
<div>On Sat, Jun 05, 2021 at 01:56:49PM +0800, Tom Yan wrot=
e:<br clear=3D"none">> As far as I'm concerned, inheriting an attribute =
from the source inode<br clear=3D"none">> isn't a "surprising" behavior.=
Rather it seems pretty "natural" to me.<br clear=3D"none">> And I don't=
think whether the attribute is "dangerous" changes that,<br clear=3D"none"=
>> because if you consider it "dangerous", shouldn't you "watch out"<br =
clear=3D"none">> anyway when you try to make a clone of a source with su=
ch an<br clear=3D"none">> attribute?<br clear=3D"none"><br clear=3D"none=
">It's important not to conflate the two contexts. For cp -a, copying=
<br clear=3D"none">attributes from the src inode might be obvious. Fo=
r any other application<br clear=3D"none">(including cp with different argu=
ments), it might be the worst possible<br clear=3D"none">thing to do, espec=
ially if we've been doing the opposite for over<br clear=3D"none">a decade.=
<br clear=3D"none"><br clear=3D"none">People run btrfs on crappy SSD and MM=
C devices, where filesystem csums<br clear=3D"none">are the only way to kno=
w the disk is failing (SMART is nonexistent,<br clear=3D"none">and the firm=
ware doesn't bother with any form of working ECC or CRC, so<br clear=3D"non=
e">the first indication of any drive failure is when it starts corrupting<b=
r clear=3D"none">data). Disabling the datasum bit on any inode is eve=
ntually equivalent<br clear=3D"none">to injecting a stream of random undete=
cted corruption into the file when<br clear=3D"none">the drive inevitably f=
ails. For users with such drives, a mount option<br clear=3D"none">or=
filesystem feature flag to disable chattr +C globally would make sense,<br=
clear=3D"none">as they never want any file to be nodatasum for any reason.=
<br clear=3D"none"><br clear=3D"none">If cp -a implements the inode attribu=
te propagation (or inheritance), then<br clear=3D"none">only users of cp -a=
are impacted. They are more likely to be aware that<br clear=3D"none=
">they may be creating new files with reduced-integrity storage attributes.=
<br clear=3D"none"><br clear=3D"none">> If we see it from the way that, =
the kernel does not make the<br clear=3D"none">> destination inherit nod=
atasum just to make reflink succeed as much as<br clear=3D"none">> possi=
ble, but rather it just by design inherit nodatacow (for the<br clear=3D"no=
ne">> reason of being NOT surprising), then there's no concern in whethe=
r<br clear=3D"none">> they should "decoupled" when we implement the inhe=
ritance. (Like we<br clear=3D"none">> can't set only nodatasum with `cha=
ttr either. It's simply out of the<br clear=3D"none">> scope then.)<br c=
lear=3D"none"><br clear=3D"none">Thw window for design of these features mo=
stly closed in 2008. If we<br clear=3D"none">limit the scope as you s=
uggest, we stuck with a lot of the current<br clear=3D"none">behavior now b=
ecause it is existing kernel API.<br clear=3D"none"><br clear=3D"none">If w=
e also fixed some of the other design issues, like the invisible<br clear=
=3D"none">datasum attribute, we could make the case that at least these aut=
omatic<br clear=3D"none">implied inode changes would be _visible to users_.=
At the moment,<br clear=3D"none">it requires special tools to inspec=
t the filesystem to see that a file<br clear=3D"none">has its nodatasum bit=
set, and we probably don't want to start silently<br clear=3D"none">flippi=
ng any more inode bits users can't even see. We already did that<br c=
lear=3D"none">with prealloc and no-compression attributes, and users find i=
t difficult<br clear=3D"none">to understand the resulting changes in btrfs =
behavior. There are some<br clear=3D"none">proposals in the works to =
make all the inode flags visible as xattr<br clear=3D"none">properties, and=
if those are done then we can say "well at least you<br clear=3D"none">can=
see that we now change the datasum attribute sometimes." But it's<br=
clear=3D"none">a very weak argument.<br clear=3D"none"><br clear=3D"none">=
The kernel has no way to know it's running 'cp -a' or that the intent<br cl=
ear=3D"none">is to copy an existing object. A user could be construct=
ing a new<br clear=3D"none">object using a combination of writes and reflin=
ks from other files<br clear=3D"none">(e.g. a disk image compiler) and inte=
nd for the result to have csums<br clear=3D"none">even if the reflinked sou=
rce files did not.<br clear=3D"none"><br clear=3D"none">The kernel only kno=
ws that it has been told to create a file with XZ<br clear=3D"none">attribu=
tes, and later the user requests cloning data from a file with<br clear=3D"=
none">XYZ attributes. If the user didn't intend for the dst file to h=
ave<br clear=3D"none">XYZ attributes (and why would she, when she created t=
he file with XZ<br clear=3D"none">attributes?), then it could be a serious =
regression if the file suddenly<br clear=3D"none">ends up with unintended Y=
attributes on new kernels. Without easy<br clear=3D"none">userspace =
visibility of the nodatasum attribute, it would be difficult<br clear=3D"no=
ne">to even _detect_ this change until after silent data corruption gets<br=
clear=3D"none">bad enough to be noticed.<br clear=3D"none"><br clear=3D"no=
ne">Contrast with the coreutils package, which has changed its behavior<br =
clear=3D"none">several times since reflink was first introduced in 2009 to =
adapt to<br clear=3D"none">changing user expectations. Nobody expects=
coreutils to behave quite<br clear=3D"none">the same way from one year to =
the next, so there is room for innovation<br clear=3D"none">there--and user=
s who don't want the innovations can fork coreutils or<br clear=3D"none">us=
e some other tools. One such innovation could be to simply detect<br =
clear=3D"none">this case and make the appropriate inode changes before copy=
ing.<br clear=3D"none"><br clear=3D"none">On the other hand, maybe nobody h=
as any existing software deployed that<br clear=3D"none">depends on the old=
kernel behavior, so we can change it after all. In the<br clear=3D"n=
one">dangerous case (cheap SSD), a sysadmin wouldn't have any nodatacow fil=
es<br clear=3D"none">anywhere on the filesystem, so they wouldn't be making=
reflink copies<br clear=3D"none">of them because none exist. They co=
uld be making a copy of a nodatacow<br clear=3D"none">file from another fil=
esystem, but in that case they would be using normal<br clear=3D"none">copy=
, since reflink doesn't work across filesystems. Maybe we can find<br=
clear=3D"none">all the users who are running reflinking disk image compile=
rs and they<br clear=3D"none">can update their code to work around the prop=
osed new kernel behavior.<br clear=3D"none"><br clear=3D"none">> I don't=
know if we can do that based on whether the reflink mode is<br clear=3D"no=
ne">> always. Though we can fallback to "normal" copy when the source ha=
s<br clear=3D"none">> nodatasum (and/or nodatacow), personally I don't f=
ind it less<br clear=3D"none">> surprising than inheriting nodatacow all=
the time.<br clear=3D"none"><br clear=3D"none">Note that the kernel never =
sees the reflink argument from cp. It is<br clear=3D"none">entirely i=
mplemented inside the 'cp' command. In --reflink=3Dauto mode,<br clea=
r=3D"none">cp will first try clone_range, and if the kernel rejects that wi=
th an<br clear=3D"none">EINVAL error, then cp will try again with tradition=
al read/write code.<br clear=3D"none">This is after cp has already created =
the dst file. The kernel does<br clear=3D"none">not provide a "create=
a new file with the attributes of an old file"<br clear=3D"none">call--cp =
has to create the file with open(), and then do a series of<br clear=3D"non=
e">chmod, chown, and setfattr calls in the right order to replicate the<br =
clear=3D"none">attributes of the old file.<br clear=3D"none"><br clear=3D"n=
one">The kernel doesn't guarantee that reflinks are possible in all cases, =
and<br clear=3D"none">generally does not provide any fallback. There =
are multiple possible<br clear=3D"none">responses to a reflink failure and =
the kernel cannot implement all<br clear=3D"none">of them. It is up t=
o userspace (i.e. the cp command) to decide what a<br clear=3D"none">correc=
t fallback behavior should be, and then implement it.<br clear=3D"none"><br=
clear=3D"none">> By the way, what will `chattr -C` do exactly if the fi=
le/inode had<br clear=3D"none">> nodatacow? Is the behavior different wh=
en it is / there is a reflink?<br clear=3D"none"><br clear=3D"none">If the =
file is empty, you can chattr +C or -C. If the file is not<br clear=
=3D"none">empty, chattr fails with an error.<br clear=3D"none"><br clear=3D=
"none">All the data extents in a file have to have the same csum status (cs=
um<br clear=3D"none">present or csum absent) as the inode. It is not =
allowed to change the<br clear=3D"none">C attribute when data extents exist=
because the C attribute indirectly<br clear=3D"none">affects whether the e=
xtents have data csums or not, and if the inode was<br clear=3D"none">chang=
ed it would disagree with existing data extents. If no data extents<b=
r clear=3D"none">exist (i.e. zero-length file), then the inode attribute ca=
n be changed,<br clear=3D"none">because there is nothing present that could=
disagree with the inode.<br clear=3D"none"><br clear=3D"none">It doesn't m=
atter whether reflinks were previously made or not. In btrfs<br clear=
=3D"none">there is no difference between a reflink and any other write, in =
the<br clear=3D"none">same way that there is no difference between a direct=
ory entry created<br clear=3D"none">by hardlink versus any other file creat=
ion. Normal writes create a<br clear=3D"none">new data extent, then r=
eflink it to exactly the spot in file where the<br clear=3D"none">data was =
written. clone_range creates a reflink to some data extent(s)<br clea=
r=3D"none">that already exist. Like hardlinks, when a reflink copy is=
made, it is<br clear=3D"none">not always possible to tell which was the or=
iginal and which was the copy.<div class=3D"ydpc369ab51yqt7672869828" id=3D=
"ydpc369ab51yqtfd89377"><br clear=3D"none"><br clear=3D"none">> On Sat, =
5 Jun 2021 at 04:16, Zygo Blaxell<br clear=3D"none">> <<a shape=3D"re=
ct" href=3D"mailto:ce3g8jdj@HIDDEN" rel=3D"nofollow" target=
=3D"_blank">ce3g8jdj@HIDDEN</a>> wrote:<br clear=3D"none"=
>> ><br clear=3D"none">> > On Fri, Jun 04, 2021 at 10:37:35PM +=
0800, Tom Yan wrote:<br clear=3D"none">> > > Also cc'ing <a shape=
=3D"rect" href=3D"mailto:bug-coreutils@HIDDEN" rel=3D"nofollow" target=3D=
"_blank">bug-coreutils@HIDDEN</a><br clear=3D"none">> > ><br cle=
ar=3D"none">> > > On Fri, 4 Jun 2021 at 22:33, Tom Yan <<a shap=
e=3D"rect" href=3D"mailto:tom.ty89@HIDDEN" rel=3D"nofollow" target=3D"_b=
lank">tom.ty89@HIDDEN</a>> wrote:<br clear=3D"none">> > > &g=
t;<br clear=3D"none">> > > > Hi all,<br clear=3D"none">> >=
; > ><br clear=3D"none">> > > > I've just bumped into a p=
roblem that I am not sure what the expected<br clear=3D"none">> > >=
; > behavior should be, but there seems to be something flawed.<br clear=
=3D"none">> > > ><br clear=3D"none">> > > > Say I h=
ave a file that was created with the No_COW attributed<br clear=3D"none">&g=
t; > > > (inherited from the directory / subvolume / mount option)=
. Then if I<br clear=3D"none">> > > > try to do a reflink copy,=
the copying will fail with "Invalid<br clear=3D"none">> > > > =
argument" if the copy has no one to inherit the No_COW attribute from.<br c=
lear=3D"none">> ><br clear=3D"none">> > Correct. nodataco=
w implies nodatasum, and you cannot reflink an extent<br clear=3D"none">>=
; > from a nodatasum inode into a datasum inode.<br clear=3D"none">> =
><br clear=3D"none">> > The result of allowing this would be a fil=
e that has some extents<br clear=3D"none">> > that have csums, and so=
me that do not. Making this work would make<br clear=3D"none">> &g=
t; reading from such a file worse (i.e. make it slower, or fail to detect<b=
r clear=3D"none">> > corruption in metadata). It's possible to =
solve some of those problems<br clear=3D"none">> > (or at least conta=
in them in inodes that are known to have mixed csum<br clear=3D"none">> =
> and non-csum data), but first someone would have to make the case that=
<br clear=3D"none">> > this is worth the effort to support.<br clear=
=3D"none">> ><br clear=3D"none">> > > > For example:<br c=
lear=3D"none">> > > > [<a shape=3D"rect" href=3D"mailto:tom@arc=
hlinux" rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mnt]$ sudo btr=
fs subvol list .<br clear=3D"none">> > > > ID 256 gen 11 top le=
vel 5 path a<br clear=3D"none">> > > > ID 257 gen 9 top level 5=
path b<br clear=3D"none">> > > > [<a shape=3D"rect" href=3D"ma=
ilto:tom@archlinux" rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mn=
t]$ lsattr<br clear=3D"none">> > > > ---------------------- ./a=
<br clear=3D"none">> > > > ---------------C------ ./b<br clear=
=3D"none">> > > > [<a shape=3D"rect" href=3D"mailto:tom@archlin=
ux" rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mnt]$ lsattr b/<br=
clear=3D"none">> > > > ---------------C------ b/test<br clear=
=3D"none">> > > > [<a shape=3D"rect" href=3D"mailto:tom@archlin=
ux" rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mnt]$ du -h b/test=
<br clear=3D"none">> > > > 512M b/test<br clear=3D=
"none">> > > > [<a shape=3D"rect" href=3D"mailto:tom@archlinux"=
rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mnt]$ lsattr a/<br cl=
ear=3D"none">> > > > [<a shape=3D"rect" href=3D"mailto:tom@arch=
linux" rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mnt]$ cp --refl=
ink=3Dalways b/test a/<br clear=3D"none">> > > > cp: failed to =
clone 'a/test' from 'b/test': Invalid argument<br clear=3D"none">> > =
> > [<a shape=3D"rect" href=3D"mailto:tom@archlinux" rel=3D"nofollow"=
target=3D"_blank">tom@archlinux</a> mnt]$ lsattr a/<br clear=3D"none">>=
> > > ---------------------- a/test<br clear=3D"none">> > &=
gt; > [<a shape=3D"rect" href=3D"mailto:tom@archlinux" rel=3D"nofollow" =
target=3D"_blank">tom@archlinux</a> mnt]$ du a/test<br clear=3D"none">> =
> > > 0 a/test<br clear=3D"none">> > > > =
[<a shape=3D"rect" href=3D"mailto:tom@archlinux" rel=3D"nofollow" target=3D=
"_blank">tom@archlinux</a> mnt]$ du --apparent-size a/test<br clear=3D"none=
">> > > > 0 a/test<br clear=3D"none">> > >=
; > [<a shape=3D"rect" href=3D"mailto:tom@archlinux" rel=3D"nofollow" ta=
rget=3D"_blank">tom@archlinux</a> mnt]$ rm a/test<br clear=3D"none">> &g=
t; > > [<a shape=3D"rect" href=3D"mailto:tom@archlinux" rel=3D"nofoll=
ow" target=3D"_blank">tom@archlinux</a> mnt]$ sudo chattr +C a/<br clear=3D=
"none">> > > > [<a shape=3D"rect" href=3D"mailto:tom@archlinux"=
rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mnt]$ cp --reflink=3D=
always b/test a/<br clear=3D"none">> > > > [<a shape=3D"rect" h=
ref=3D"mailto:tom@archlinux" rel=3D"nofollow" target=3D"_blank">tom@archlin=
ux</a> mnt]$ lsattr a/<br clear=3D"none">> > > > --------------=
-C------ a/test<br clear=3D"none">> > > > [<a shape=3D"rect" hr=
ef=3D"mailto:tom@archlinux" rel=3D"nofollow" target=3D"_blank">tom@archlinu=
x</a> mnt]$ cmp b/test a/test<br clear=3D"none">> > > > [<a sha=
pe=3D"rect" href=3D"mailto:tom@archlinux" rel=3D"nofollow" target=3D"_blank=
">tom@archlinux</a> mnt]$<br clear=3D"none">> > > ><br clear=3D=
"none">> > > > I'm not entirely sure if a reflink copy is suppo=
sed to work for a<br clear=3D"none">> > > > source file that wa=
s created with No_COW, but apparently it is.<br clear=3D"none">> ><br=
clear=3D"none">> > Snapshots are also allowed for nodatacow files.&n=
bsp; The extents that are<br clear=3D"none">> > shared become implici=
tly datacow until they are not shared any more.<br clear=3D"none">> >=
<br clear=3D"none">> > Snapshots are deferred reflink copies, so it w=
ould be difficult to<br clear=3D"none">> > allow one and not the othe=
r. Disallowing both seems overly restrictive<br clear=3D"none">> &=
gt; (e.g. with such a restriction, it would not be possible to use 'btrfs<b=
r clear=3D"none">> > send' or make a snapshot on a subvol that contai=
ns any nodatacow file).<br clear=3D"none">> ><br clear=3D"none">> =
> btrfs did disallow both operations for swap files, so it could be poss=
ible<br clear=3D"none">> > to disallow both reflinks and snapshots fo=
r nodatacow files, but AFAIK<br clear=3D"none">> > nobody wants that =
(some people even want the swapfile restrictions to<br clear=3D"none">> =
> go away someday).<br clear=3D"none">> ><br clear=3D"none">> &=
gt; > > The<br clear=3D"none">> > > > problem is just tha=
t the reflink copy also needs to have the attribute<br clear=3D"none">> =
> > > set, yet it cannot inherit from the source automatically.<br=
clear=3D"none">> ><br clear=3D"none">> > reflink can only refl=
ink copy from one nodatasum file to another nodatasum<br clear=3D"none">>=
; > file, or from one datasum file to another datasum file.<br clear=3D"=
none">> ><br clear=3D"none">> > An empty inode can be changed f=
rom datacow to nodatacow (or vice versa)<br clear=3D"none">> > using =
the fsattr ioctl, which simultaneously changes the file from<br clear=3D"no=
ne">> > datasum to nodatasum if the filesystem was not mounted with t=
he nodatasum<br clear=3D"none">> > mount option.<br clear=3D"none">&g=
t; ><br clear=3D"none">> > There is a possible kernel enhancement =
here: when an empty inode is the<br clear=3D"none">> > dst of a=
reflink, automatically change the reflink dst inode's nodatasum<br clear=
=3D"none">> > flag to match the reflink src inode's nodatasum flag.&n=
bsp; If the dst inode<br clear=3D"none">> > is not empty and the inod=
e datasum flags do not match, then reject the<br clear=3D"none">> > r=
eflink with EINVAL as before.<br clear=3D"none">> ><br clear=3D"none"=
>> > It's not clear whether this should apply only to nodatasum or al=
so to<br clear=3D"none">> > nodatacow. reflink doesn't need src=
and dst agreement on nodatacow,<br clear=3D"none">> > so the dst ino=
de could be a nodatasum+datacow file. Unfortunately all<br clear=3D"n=
one">> > the userspace tools including coreutils can only see the nod=
atacow<br clear=3D"none">> > inode bit, not the nodatasum bit, so the=
lack of csums on the dst file<br clear=3D"none">> > would be invisib=
le. The kernel cannot know the user's intent from the<br clear=3D"non=
e">> > available information.<br clear=3D"none">> ><br clear=3D=
"none">> > It's not clear that we want the kernel to be implicitly ch=
anging<br clear=3D"none">> > inode attribute bits like this--especial=
ly bits that disable integrity<br clear=3D"none">> > features like no=
datasum. There is precedent for changing fsattrs with<br clear=3D"non=
e">> > the no-compress inode flag, but that flag doesn't disable csum=
s, and<br clear=3D"none">> > this one would.<br clear=3D"none">> &=
gt;<br clear=3D"none">> > One could also make the opposite case: =
; it should always be an error to<br clear=3D"none">> > do anything t=
hat would put data in a datasum file without csums, the<br clear=3D"none">&=
gt; > existing behavior is correct, and should not be changed. The=
problem<br clear=3D"none">> > with this argument is that users can't=
see the datasum inode bits,<br clear=3D"none">> > so it's not clear =
that the EINVAL is a data protection mechanism.<br clear=3D"none">> >=
<br clear=3D"none">> > > > I wonder if this is a kernel-side pr=
oblem or something that coreutils<br clear=3D"none">> > > > mis=
sed? It also seems wrong that when it fails there will be an empty<br clear=
=3D"none">> > > > destination file created.<br clear=3D"none">&=
gt; ><br clear=3D"none">> > Normally coreutils will fall back to s=
imple copy if --reflink=3Dauto<br clear=3D"none">> > is used. -=
-reflink=3Dalways is the user's explicit request for "reflink<br clear=3D"n=
one">> > or nothing, please." The user correctly got nothing, a=
s requested.<br clear=3D"none">> ><br clear=3D"none">> > On oth=
er filesystems, reflink on a nodatacow file might make a simple<br clear=3D=
"none">> > copy in the kernel--in which case you are no better off th=
an if you had<br clear=3D"none">> > used --reflink=3Dauto.<br clear=
=3D"none">> ><br clear=3D"none">> > coreutils could propagate t=
he source inode nodatacow fsattribute to<br clear=3D"none">> > the de=
stination inode if it intends to use reflink to copy the data.<br clear=3D"=
none">> > That would be the userspace equivalent of the kernel enhanc=
ement I<br clear=3D"none">> > suggested above. It would probabl=
y match user expectations better--no<br clear=3D"none">> > hidden sur=
prises for non-coreutils use cases, and all the affected inode<br clear=3D"=
none">> > attribute bits are necessarily visible in userspace.<br cle=
ar=3D"none">> ><br clear=3D"none">> > fsattr propagation could =
be quite complicated for coreutils to implement<br clear=3D"none">> >=
correctly in general, as some fsattrs should not be propagated this way,<b=
r clear=3D"none">> > and other filesystems may have different restric=
tions. Some fsattrs must<br clear=3D"none">> > be set before th=
e data is written (e.g. -c for compression), others must<br clear=3D"none">=
> > be set after the data is written (e.g. -i for immutable), and som=
e are<br clear=3D"none">> > a matter of user intent (e.g. should a si=
mple copy be compressed if the<br clear=3D"none">> > source is not?&n=
bsp; Depends on the intended use of the copy).<br clear=3D"none">> ><=
br clear=3D"none">> > On other filesystems this userspace behavior mi=
ght trigger the opposite<br clear=3D"none">> > of the intended kernel=
behavior, causing reflink to always fall back to<br clear=3D"none">> &g=
t; simple copy because the dst inode's nodatacow attribute is set.<br clear=
=3D"none">> ><br clear=3D"none">> > Ideally btrfs will not forc=
e coreutils to do one thing on btrfs and the<br clear=3D"none">> > op=
posite thing on other filesystems, so it might be worthwhile to hack<br cle=
ar=3D"none">> > around this in the kernel as proposed above. Th=
ere is precedent for<br clear=3D"none">> > that--btrfs falls back to =
simple copy in reflinks of inline extents,<br clear=3D"none">> > more=
or less for the sole purpose of making cp --reflink=3Dalways not fail<br c=
lear=3D"none">> > so randomly.<br clear=3D"none">> ><br clear=
=3D"none">> > > > Kernel version: Linux archlinux 5.12.8-arch1-=
1 #1 SMP PREEMPT Fri, 28<br clear=3D"none">> > > > May 2021 15:=
10:20 +0000 x86_64 GNU/Linux<br clear=3D"none">> > > > Coreutil=
s version: 8.32<br clear=3D"none">> > > ><br clear=3D"none">>=
; > > > Regards,<br clear=3D"none">> > > > Tom<br clea=
r=3D"none"><br clear=3D"none"><br clear=3D"none"><br clear=3D"none"></div><=
/div>
</div>
</div></body></html>
------=_Part_4286188_894301194.1623031252967--
bug-coreutils@HIDDEN:bug#48833; Package coreutils.
Full text available.Received: (at submit) by debbugs.gnu.org; 6 Jun 2021 08:42:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jun 06 04:42:25 2021 Received: from localhost ([127.0.0.1]:50589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1lpoMS-0002Rm-02 for submit <at> debbugs.gnu.org; Sun, 06 Jun 2021 04:42:24 -0400 Received: from lists.gnu.org ([209.51.188.17]:44340) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <postmaster@HIDDEN>) id 1lplYc-0006Qd-VD for submit <at> debbugs.gnu.org; Sun, 06 Jun 2021 01:42:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40176) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>) id 1lplYc-00069P-MM for bug-coreutils@HIDDEN; Sun, 06 Jun 2021 01:42:46 -0400 Received: from james.kirk.hungrycats.org ([174.142.39.145]:40934) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>) id 1lplYa-00031H-7Q for bug-coreutils@HIDDEN; Sun, 06 Jun 2021 01:42:46 -0400 Received: by james.kirk.hungrycats.org (Postfix, from userid 1002) id CC7DAA8F1A9; Sun, 6 Jun 2021 01:42:42 -0400 (EDT) Date: Sun, 6 Jun 2021 01:42:42 -0400 From: Zygo Blaxell <ce3g8jdj@HIDDEN> To: Tom Yan <tom.ty89@HIDDEN> Subject: Re: reflink copying does not check/set No_COW attribute and fail Message-ID: <20210606054242.GI11733@HIDDEN> References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN> <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN> <20210604201630.GH11733@HIDDEN> <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN> User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: pass client-ip=174.142.39.145; envelope-from=postmaster@HIDDEN; helo=james.kirk.hungrycats.org X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 06 Jun 2021 04:42:21 -0400 Cc: bug-coreutils@HIDDEN, linux-btrfs@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On Sat, Jun 05, 2021 at 01:56:49PM +0800, Tom Yan wrote: > As far as I'm concerned, inheriting an attribute from the source inode > isn't a "surprising" behavior. Rather it seems pretty "natural" to me. > And I don't think whether the attribute is "dangerous" changes that, > because if you consider it "dangerous", shouldn't you "watch out" > anyway when you try to make a clone of a source with such an > attribute? It's important not to conflate the two contexts. For cp -a, copying attributes from the src inode might be obvious. For any other application (including cp with different arguments), it might be the worst possible thing to do, especially if we've been doing the opposite for over a decade. People run btrfs on crappy SSD and MMC devices, where filesystem csums are the only way to know the disk is failing (SMART is nonexistent, and the firmware doesn't bother with any form of working ECC or CRC, so the first indication of any drive failure is when it starts corrupting data). Disabling the datasum bit on any inode is eventually equivalent to injecting a stream of random undetected corruption into the file when the drive inevitably fails. For users with such drives, a mount option or filesystem feature flag to disable chattr +C globally would make sense, as they never want any file to be nodatasum for any reason. If cp -a implements the inode attribute propagation (or inheritance), then only users of cp -a are impacted. They are more likely to be aware that they may be creating new files with reduced-integrity storage attributes. > If we see it from the way that, the kernel does not make the > destination inherit nodatasum just to make reflink succeed as much as > possible, but rather it just by design inherit nodatacow (for the > reason of being NOT surprising), then there's no concern in whether > they should "decoupled" when we implement the inheritance. (Like we > can't set only nodatasum with `chattr either. It's simply out of the > scope then.) Thw window for design of these features mostly closed in 2008. If we limit the scope as you suggest, we stuck with a lot of the current behavior now because it is existing kernel API. If we also fixed some of the other design issues, like the invisible datasum attribute, we could make the case that at least these automatic implied inode changes would be _visible to users_. At the moment, it requires special tools to inspect the filesystem to see that a file has its nodatasum bit set, and we probably don't want to start silently flipping any more inode bits users can't even see. We already did that with prealloc and no-compression attributes, and users find it difficult to understand the resulting changes in btrfs behavior. There are some proposals in the works to make all the inode flags visible as xattr properties, and if those are done then we can say "well at least you can see that we now change the datasum attribute sometimes." But it's a very weak argument. The kernel has no way to know it's running 'cp -a' or that the intent is to copy an existing object. A user could be constructing a new object using a combination of writes and reflinks from other files (e.g. a disk image compiler) and intend for the result to have csums even if the reflinked source files did not. The kernel only knows that it has been told to create a file with XZ attributes, and later the user requests cloning data from a file with XYZ attributes. If the user didn't intend for the dst file to have XYZ attributes (and why would she, when she created the file with XZ attributes?), then it could be a serious regression if the file suddenly ends up with unintended Y attributes on new kernels. Without easy userspace visibility of the nodatasum attribute, it would be difficult to even _detect_ this change until after silent data corruption gets bad enough to be noticed. Contrast with the coreutils package, which has changed its behavior several times since reflink was first introduced in 2009 to adapt to changing user expectations. Nobody expects coreutils to behave quite the same way from one year to the next, so there is room for innovation there--and users who don't want the innovations can fork coreutils or use some other tools. One such innovation could be to simply detect this case and make the appropriate inode changes before copying. On the other hand, maybe nobody has any existing software deployed that depends on the old kernel behavior, so we can change it after all. In the dangerous case (cheap SSD), a sysadmin wouldn't have any nodatacow files anywhere on the filesystem, so they wouldn't be making reflink copies of them because none exist. They could be making a copy of a nodatacow file from another filesystem, but in that case they would be using normal copy, since reflink doesn't work across filesystems. Maybe we can find all the users who are running reflinking disk image compilers and they can update their code to work around the proposed new kernel behavior. > I don't know if we can do that based on whether the reflink mode is > always. Though we can fallback to "normal" copy when the source has > nodatasum (and/or nodatacow), personally I don't find it less > surprising than inheriting nodatacow all the time. Note that the kernel never sees the reflink argument from cp. It is entirely implemented inside the 'cp' command. In --reflink=auto mode, cp will first try clone_range, and if the kernel rejects that with an EINVAL error, then cp will try again with traditional read/write code. This is after cp has already created the dst file. The kernel does not provide a "create a new file with the attributes of an old file" call--cp has to create the file with open(), and then do a series of chmod, chown, and setfattr calls in the right order to replicate the attributes of the old file. The kernel doesn't guarantee that reflinks are possible in all cases, and generally does not provide any fallback. There are multiple possible responses to a reflink failure and the kernel cannot implement all of them. It is up to userspace (i.e. the cp command) to decide what a correct fallback behavior should be, and then implement it. > By the way, what will `chattr -C` do exactly if the file/inode had > nodatacow? Is the behavior different when it is / there is a reflink? If the file is empty, you can chattr +C or -C. If the file is not empty, chattr fails with an error. All the data extents in a file have to have the same csum status (csum present or csum absent) as the inode. It is not allowed to change the C attribute when data extents exist because the C attribute indirectly affects whether the extents have data csums or not, and if the inode was changed it would disagree with existing data extents. If no data extents exist (i.e. zero-length file), then the inode attribute can be changed, because there is nothing present that could disagree with the inode. It doesn't matter whether reflinks were previously made or not. In btrfs there is no difference between a reflink and any other write, in the same way that there is no difference between a directory entry created by hardlink versus any other file creation. Normal writes create a new data extent, then reflink it to exactly the spot in file where the data was written. clone_range creates a reflink to some data extent(s) that already exist. Like hardlinks, when a reflink copy is made, it is not always possible to tell which was the original and which was the copy. > On Sat, 5 Jun 2021 at 04:16, Zygo Blaxell > <ce3g8jdj@HIDDEN> wrote: > > > > On Fri, Jun 04, 2021 at 10:37:35PM +0800, Tom Yan wrote: > > > Also cc'ing bug-coreutils@HIDDEN > > > > > > On Fri, 4 Jun 2021 at 22:33, Tom Yan <tom.ty89@HIDDEN> wrote: > > > > > > > > Hi all, > > > > > > > > I've just bumped into a problem that I am not sure what the expected > > > > behavior should be, but there seems to be something flawed. > > > > > > > > Say I have a file that was created with the No_COW attributed > > > > (inherited from the directory / subvolume / mount option). Then if I > > > > try to do a reflink copy, the copying will fail with "Invalid > > > > argument" if the copy has no one to inherit the No_COW attribute from. > > > > Correct. nodatacow implies nodatasum, and you cannot reflink an extent > > from a nodatasum inode into a datasum inode. > > > > The result of allowing this would be a file that has some extents > > that have csums, and some that do not. Making this work would make > > reading from such a file worse (i.e. make it slower, or fail to detect > > corruption in metadata). It's possible to solve some of those problems > > (or at least contain them in inodes that are known to have mixed csum > > and non-csum data), but first someone would have to make the case that > > this is worth the effort to support. > > > > > > For example: > > > > [tom@archlinux mnt]$ sudo btrfs subvol list . > > > > ID 256 gen 11 top level 5 path a > > > > ID 257 gen 9 top level 5 path b > > > > [tom@archlinux mnt]$ lsattr > > > > ---------------------- ./a > > > > ---------------C------ ./b > > > > [tom@archlinux mnt]$ lsattr b/ > > > > ---------------C------ b/test > > > > [tom@archlinux mnt]$ du -h b/test > > > > 512M b/test > > > > [tom@archlinux mnt]$ lsattr a/ > > > > [tom@archlinux mnt]$ cp --reflink=always b/test a/ > > > > cp: failed to clone 'a/test' from 'b/test': Invalid argument > > > > [tom@archlinux mnt]$ lsattr a/ > > > > ---------------------- a/test > > > > [tom@archlinux mnt]$ du a/test > > > > 0 a/test > > > > [tom@archlinux mnt]$ du --apparent-size a/test > > > > 0 a/test > > > > [tom@archlinux mnt]$ rm a/test > > > > [tom@archlinux mnt]$ sudo chattr +C a/ > > > > [tom@archlinux mnt]$ cp --reflink=always b/test a/ > > > > [tom@archlinux mnt]$ lsattr a/ > > > > ---------------C------ a/test > > > > [tom@archlinux mnt]$ cmp b/test a/test > > > > [tom@archlinux mnt]$ > > > > > > > > I'm not entirely sure if a reflink copy is supposed to work for a > > > > source file that was created with No_COW, but apparently it is. > > > > Snapshots are also allowed for nodatacow files. The extents that are > > shared become implicitly datacow until they are not shared any more. > > > > Snapshots are deferred reflink copies, so it would be difficult to > > allow one and not the other. Disallowing both seems overly restrictive > > (e.g. with such a restriction, it would not be possible to use 'btrfs > > send' or make a snapshot on a subvol that contains any nodatacow file). > > > > btrfs did disallow both operations for swap files, so it could be possible > > to disallow both reflinks and snapshots for nodatacow files, but AFAIK > > nobody wants that (some people even want the swapfile restrictions to > > go away someday). > > > > > > The > > > > problem is just that the reflink copy also needs to have the attribute > > > > set, yet it cannot inherit from the source automatically. > > > > reflink can only reflink copy from one nodatasum file to another nodatasum > > file, or from one datasum file to another datasum file. > > > > An empty inode can be changed from datacow to nodatacow (or vice versa) > > using the fsattr ioctl, which simultaneously changes the file from > > datasum to nodatasum if the filesystem was not mounted with the nodatasum > > mount option. > > > > There is a possible kernel enhancement here: when an empty inode is the > > dst of a reflink, automatically change the reflink dst inode's nodatasum > > flag to match the reflink src inode's nodatasum flag. If the dst inode > > is not empty and the inode datasum flags do not match, then reject the > > reflink with EINVAL as before. > > > > It's not clear whether this should apply only to nodatasum or also to > > nodatacow. reflink doesn't need src and dst agreement on nodatacow, > > so the dst inode could be a nodatasum+datacow file. Unfortunately all > > the userspace tools including coreutils can only see the nodatacow > > inode bit, not the nodatasum bit, so the lack of csums on the dst file > > would be invisible. The kernel cannot know the user's intent from the > > available information. > > > > It's not clear that we want the kernel to be implicitly changing > > inode attribute bits like this--especially bits that disable integrity > > features like nodatasum. There is precedent for changing fsattrs with > > the no-compress inode flag, but that flag doesn't disable csums, and > > this one would. > > > > One could also make the opposite case: it should always be an error to > > do anything that would put data in a datasum file without csums, the > > existing behavior is correct, and should not be changed. The problem > > with this argument is that users can't see the datasum inode bits, > > so it's not clear that the EINVAL is a data protection mechanism. > > > > > > I wonder if this is a kernel-side problem or something that coreutils > > > > missed? It also seems wrong that when it fails there will be an empty > > > > destination file created. > > > > Normally coreutils will fall back to simple copy if --reflink=auto > > is used. --reflink=always is the user's explicit request for "reflink > > or nothing, please." The user correctly got nothing, as requested. > > > > On other filesystems, reflink on a nodatacow file might make a simple > > copy in the kernel--in which case you are no better off than if you had > > used --reflink=auto. > > > > coreutils could propagate the source inode nodatacow fsattribute to > > the destination inode if it intends to use reflink to copy the data. > > That would be the userspace equivalent of the kernel enhancement I > > suggested above. It would probably match user expectations better--no > > hidden surprises for non-coreutils use cases, and all the affected inode > > attribute bits are necessarily visible in userspace. > > > > fsattr propagation could be quite complicated for coreutils to implement > > correctly in general, as some fsattrs should not be propagated this way, > > and other filesystems may have different restrictions. Some fsattrs must > > be set before the data is written (e.g. -c for compression), others must > > be set after the data is written (e.g. -i for immutable), and some are > > a matter of user intent (e.g. should a simple copy be compressed if the > > source is not? Depends on the intended use of the copy). > > > > On other filesystems this userspace behavior might trigger the opposite > > of the intended kernel behavior, causing reflink to always fall back to > > simple copy because the dst inode's nodatacow attribute is set. > > > > Ideally btrfs will not force coreutils to do one thing on btrfs and the > > opposite thing on other filesystems, so it might be worthwhile to hack > > around this in the kernel as proposed above. There is precedent for > > that--btrfs falls back to simple copy in reflinks of inline extents, > > more or less for the sole purpose of making cp --reflink=always not fail > > so randomly. > > > > > > Kernel version: Linux archlinux 5.12.8-arch1-1 #1 SMP PREEMPT Fri, 28 > > > > May 2021 15:10:20 +0000 x86_64 GNU/Linux > > > > Coreutils version: 8.32 > > > > > > > > Regards, > > > > Tom
bug-coreutils@HIDDEN:bug#48833; Package coreutils.
Full text available.Received: (at submit) by debbugs.gnu.org; 5 Jun 2021 16:20:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 05 12:20:42 2021 Received: from localhost ([127.0.0.1]:49948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1lpZ2O-0008LL-GJ for submit <at> debbugs.gnu.org; Sat, 05 Jun 2021 12:20:42 -0400 Received: from lists.gnu.org ([209.51.188.17]:40708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <postmaster@HIDDEN>) id 1lpTej-0005wU-Bt for submit <at> debbugs.gnu.org; Sat, 05 Jun 2021 06:35:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55736) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>) id 1lpTej-0002Cs-3T for bug-coreutils@HIDDEN; Sat, 05 Jun 2021 06:35:53 -0400 Received: from pio-pvt-msa3.bahnhof.se ([79.136.2.42]:35834) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>) id 1lpTef-00067R-PP for bug-coreutils@HIDDEN; Sat, 05 Jun 2021 06:35:52 -0400 Received: from localhost (localhost [127.0.0.1]) by pio-pvt-msa3.bahnhof.se (Postfix) with ESMTP id AF3464590B; Sat, 5 Jun 2021 12:35:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bahnhof.se X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=6.31 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from pio-pvt-msa3.bahnhof.se ([127.0.0.1]) by localhost (pio-pvt-msa3.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_TPGxVMZjiY; Sat, 5 Jun 2021 12:35:45 +0200 (CEST) Received: by pio-pvt-msa3.bahnhof.se (Postfix) with ESMTPA id C82713FBCD; Sat, 5 Jun 2021 12:35:44 +0200 (CEST) Received: from [192.168.0.10] (port=59537) by tnonline.net with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <forza@HIDDEN>) id 1lpTec-000NAH-2k; Sat, 05 Jun 2021 12:35:44 +0200 Subject: Re: reflink copying does not check/set No_COW attribute and fail To: Tom Yan <tom.ty89@HIDDEN>, Zygo Blaxell <ce3g8jdj@HIDDEN> References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN> <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN> <20210604201630.GH11733@HIDDEN> <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN> From: Forza <forza@HIDDEN> Message-ID: <56d734d0-d0f6-4d64-7b6f-9ea8ad2858d4@HIDDEN> Date: Sat, 5 Jun 2021 12:35:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=79.136.2.42; envelope-from=postmaster@HIDDEN; helo=pio-pvt-msa3.bahnhof.se X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.59, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sat, 05 Jun 2021 12:20:38 -0400 Cc: bug-coreutils@HIDDEN, linux-btrfs@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.0 (---) On 2021-06-05 07:56, Tom Yan wrote: > As far as I'm concerned, inheriting an attribute from the source inode > isn't a "surprising" behavior. Rather it seems pretty "natural" to me. > And I don't think whether the attribute is "dangerous" changes that, > because if you consider it "dangerous", shouldn't you "watch out" > anyway when you try to make a clone of a source with such an > attribute? I'd agree here. 'cp -a' does mean preserve all attrributes. It is up the user to think about consequences copying nodatacow files. > > If we see it from the way that, the kernel does not make the > destination inherit nodatasum just to make reflink succeed as much as > possible, but rather it just by design inherit nodatacow (for the > reason of being NOT surprising), then there's no concern in whether > they should "decoupled" when we implement the inheritance. (Like we > can't set only nodatasum with `chattr either. It's simply out of the > scope then.) > > I don't know if we can do that based on whether the reflink mode is > always. Though we can fallback to "normal" copy when the source has > nodatasum (and/or nodatacow), personally I don't find it less > surprising than inheriting nodatacow all the time. > > By the way, what will `chattr -C` do exactly if the file/inode had > nodatacow? Is the behavior different when it is / there is a reflink? You cannot disable nodatacow on a file with existing contents. There is already a thread from May 2020 on coreutils mailing list about the order of copying attributes to solve the issue of nodatacow etc. Basically, 'cp -a' needs to set some file attributes before adding data to them. https://lists.gnu.org/archive/html/coreutils/2020-05/msg00011.html
bug-coreutils@HIDDEN:bug#48833; Package coreutils.
Full text available.Received: (at submit) by debbugs.gnu.org; 5 Jun 2021 05:57:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 05 01:57:08 2021 Received: from localhost ([127.0.0.1]:48225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1lpPIx-0005PY-CJ for submit <at> debbugs.gnu.org; Sat, 05 Jun 2021 01:57:07 -0400 Received: from lists.gnu.org ([209.51.188.17]:52254) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <tom.ty89@HIDDEN>) id 1lpPIv-0005PQ-9L for submit <at> debbugs.gnu.org; Sat, 05 Jun 2021 01:57:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46920) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <tom.ty89@HIDDEN>) id 1lpPIu-0000rf-W4 for bug-coreutils@HIDDEN; Sat, 05 Jun 2021 01:57:05 -0400 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]:41936) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <tom.ty89@HIDDEN>) id 1lpPIs-0005kI-NY for bug-coreutils@HIDDEN; Sat, 05 Jun 2021 01:57:04 -0400 Received: by mail-lf1-x131.google.com with SMTP id v8so17273571lft.8 for <bug-coreutils@HIDDEN>; Fri, 04 Jun 2021 22:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q/TMKt1vz2yxQfR44nraDhRCGhELOpEPek0prmsDDnQ=; b=U0bYlY9CIKmU+RKKaruKPZwuMf6rmcpuVjAFeslsoHqKhSWEYrW6AXWXy5/wLzLH5f wHXKsJSWCEAb4UDvlxbRVsrCt+FsYsYh7sIya06rFVtaq1trE9d5piXwzd3oIelmq131 I7B+t9DVhEdcaAdJPCVyENb1ynnlrsExT01E2enCHDMZ1++C/VH5iONqDnpbPltoXsBm wJdQijM+vY6ykOzOlpMGHBHTJ727URBRZGqGn/jdTOMsZ0++QMCWKWl4sAlsoOd5mUtp 9tLqUROU+XbFUX38kkqStI7FrSiLQeMvMLs9OHepNfdhaTS2OImEl9NiATgb6lrAL2U+ eUWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q/TMKt1vz2yxQfR44nraDhRCGhELOpEPek0prmsDDnQ=; b=DuJeBj9O4jnrK09yfRXbblxvrruUSjXBRrfSZ9/gXBsDyNT2zrrf1fmP66VZID+/4+ 1+FUsIwipE99Hi6w7Q7tBi/VSMNudXRYnkEhw5PfXly2RIS5J1Qa66wqc5bhQ/ZZ4s// TFAwXrdgDFn8A/c/Ui/IQbrBF12NrmGuJrGT0H5BiFYVdh7WgGgemY1yIgOgpMj+BLVu 2DwnwT7KugAhxskDve8V6keEqMZ6/k00UhgbgMNdQ7z44ElHlhTM4wCZMUhRu78OAzhs A9whHYTgeSvXh/0kDgvsCLuJ1JB9VZuf7EmBdQCsL2AWaR7EItG1XyQeT6ctOtlSFNca NMOA== X-Gm-Message-State: AOAM530dskKym461IprWQYbIoT3G8JcOh1q4TzrbZfmVeCJstJgA/VpO kMF22LVuhC/Jiu2JXfNQ7xGxAm2iIj4ZtBVzntA= X-Google-Smtp-Source: ABdhPJyHU32dhvrw9keJqUTgxXDv4yjMNaeFj3S57E7F7/PVyBl83SPnYAnlMCLe71AGwWkVrYC5j2KFzcB9UQ1gIHo= X-Received: by 2002:a05:6512:1327:: with SMTP id x39mr5050278lfu.37.1622872620963; Fri, 04 Jun 2021 22:57:00 -0700 (PDT) MIME-Version: 1.0 References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN> <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN> <20210604201630.GH11733@HIDDEN> In-Reply-To: <20210604201630.GH11733@HIDDEN> From: Tom Yan <tom.ty89@HIDDEN> Date: Sat, 5 Jun 2021 13:56:49 +0800 Message-ID: <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN> Subject: Re: reflink copying does not check/set No_COW attribute and fail To: Zygo Blaxell <ce3g8jdj@HIDDEN> Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=tom.ty89@HIDDEN; helo=mail-lf1-x131.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: submit Cc: bug-coreutils@HIDDEN, linux-btrfs@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) As far as I'm concerned, inheriting an attribute from the source inode isn't a "surprising" behavior. Rather it seems pretty "natural" to me. And I don't think whether the attribute is "dangerous" changes that, because if you consider it "dangerous", shouldn't you "watch out" anyway when you try to make a clone of a source with such an attribute? If we see it from the way that, the kernel does not make the destination inherit nodatasum just to make reflink succeed as much as possible, but rather it just by design inherit nodatacow (for the reason of being NOT surprising), then there's no concern in whether they should "decoupled" when we implement the inheritance. (Like we can't set only nodatasum with `chattr either. It's simply out of the scope then.) I don't know if we can do that based on whether the reflink mode is always. Though we can fallback to "normal" copy when the source has nodatasum (and/or nodatacow), personally I don't find it less surprising than inheriting nodatacow all the time. By the way, what will `chattr -C` do exactly if the file/inode had nodatacow? Is the behavior different when it is / there is a reflink? On Sat, 5 Jun 2021 at 04:16, Zygo Blaxell <ce3g8jdj@HIDDEN> wrote: > > On Fri, Jun 04, 2021 at 10:37:35PM +0800, Tom Yan wrote: > > Also cc'ing bug-coreutils@HIDDEN > > > > On Fri, 4 Jun 2021 at 22:33, Tom Yan <tom.ty89@HIDDEN> wrote: > > > > > > Hi all, > > > > > > I've just bumped into a problem that I am not sure what the expected > > > behavior should be, but there seems to be something flawed. > > > > > > Say I have a file that was created with the No_COW attributed > > > (inherited from the directory / subvolume / mount option). Then if I > > > try to do a reflink copy, the copying will fail with "Invalid > > > argument" if the copy has no one to inherit the No_COW attribute from. > > Correct. nodatacow implies nodatasum, and you cannot reflink an extent > from a nodatasum inode into a datasum inode. > > The result of allowing this would be a file that has some extents > that have csums, and some that do not. Making this work would make > reading from such a file worse (i.e. make it slower, or fail to detect > corruption in metadata). It's possible to solve some of those problems > (or at least contain them in inodes that are known to have mixed csum > and non-csum data), but first someone would have to make the case that > this is worth the effort to support. > > > > For example: > > > [tom@archlinux mnt]$ sudo btrfs subvol list . > > > ID 256 gen 11 top level 5 path a > > > ID 257 gen 9 top level 5 path b > > > [tom@archlinux mnt]$ lsattr > > > ---------------------- ./a > > > ---------------C------ ./b > > > [tom@archlinux mnt]$ lsattr b/ > > > ---------------C------ b/test > > > [tom@archlinux mnt]$ du -h b/test > > > 512M b/test > > > [tom@archlinux mnt]$ lsattr a/ > > > [tom@archlinux mnt]$ cp --reflink=always b/test a/ > > > cp: failed to clone 'a/test' from 'b/test': Invalid argument > > > [tom@archlinux mnt]$ lsattr a/ > > > ---------------------- a/test > > > [tom@archlinux mnt]$ du a/test > > > 0 a/test > > > [tom@archlinux mnt]$ du --apparent-size a/test > > > 0 a/test > > > [tom@archlinux mnt]$ rm a/test > > > [tom@archlinux mnt]$ sudo chattr +C a/ > > > [tom@archlinux mnt]$ cp --reflink=always b/test a/ > > > [tom@archlinux mnt]$ lsattr a/ > > > ---------------C------ a/test > > > [tom@archlinux mnt]$ cmp b/test a/test > > > [tom@archlinux mnt]$ > > > > > > I'm not entirely sure if a reflink copy is supposed to work for a > > > source file that was created with No_COW, but apparently it is. > > Snapshots are also allowed for nodatacow files. The extents that are > shared become implicitly datacow until they are not shared any more. > > Snapshots are deferred reflink copies, so it would be difficult to > allow one and not the other. Disallowing both seems overly restrictive > (e.g. with such a restriction, it would not be possible to use 'btrfs > send' or make a snapshot on a subvol that contains any nodatacow file). > > btrfs did disallow both operations for swap files, so it could be possible > to disallow both reflinks and snapshots for nodatacow files, but AFAIK > nobody wants that (some people even want the swapfile restrictions to > go away someday). > > > > The > > > problem is just that the reflink copy also needs to have the attribute > > > set, yet it cannot inherit from the source automatically. > > reflink can only reflink copy from one nodatasum file to another nodatasum > file, or from one datasum file to another datasum file. > > An empty inode can be changed from datacow to nodatacow (or vice versa) > using the fsattr ioctl, which simultaneously changes the file from > datasum to nodatasum if the filesystem was not mounted with the nodatasum > mount option. > > There is a possible kernel enhancement here: when an empty inode is the > dst of a reflink, automatically change the reflink dst inode's nodatasum > flag to match the reflink src inode's nodatasum flag. If the dst inode > is not empty and the inode datasum flags do not match, then reject the > reflink with EINVAL as before. > > It's not clear whether this should apply only to nodatasum or also to > nodatacow. reflink doesn't need src and dst agreement on nodatacow, > so the dst inode could be a nodatasum+datacow file. Unfortunately all > the userspace tools including coreutils can only see the nodatacow > inode bit, not the nodatasum bit, so the lack of csums on the dst file > would be invisible. The kernel cannot know the user's intent from the > available information. > > It's not clear that we want the kernel to be implicitly changing > inode attribute bits like this--especially bits that disable integrity > features like nodatasum. There is precedent for changing fsattrs with > the no-compress inode flag, but that flag doesn't disable csums, and > this one would. > > One could also make the opposite case: it should always be an error to > do anything that would put data in a datasum file without csums, the > existing behavior is correct, and should not be changed. The problem > with this argument is that users can't see the datasum inode bits, > so it's not clear that the EINVAL is a data protection mechanism. > > > > I wonder if this is a kernel-side problem or something that coreutils > > > missed? It also seems wrong that when it fails there will be an empty > > > destination file created. > > Normally coreutils will fall back to simple copy if --reflink=auto > is used. --reflink=always is the user's explicit request for "reflink > or nothing, please." The user correctly got nothing, as requested. > > On other filesystems, reflink on a nodatacow file might make a simple > copy in the kernel--in which case you are no better off than if you had > used --reflink=auto. > > coreutils could propagate the source inode nodatacow fsattribute to > the destination inode if it intends to use reflink to copy the data. > That would be the userspace equivalent of the kernel enhancement I > suggested above. It would probably match user expectations better--no > hidden surprises for non-coreutils use cases, and all the affected inode > attribute bits are necessarily visible in userspace. > > fsattr propagation could be quite complicated for coreutils to implement > correctly in general, as some fsattrs should not be propagated this way, > and other filesystems may have different restrictions. Some fsattrs must > be set before the data is written (e.g. -c for compression), others must > be set after the data is written (e.g. -i for immutable), and some are > a matter of user intent (e.g. should a simple copy be compressed if the > source is not? Depends on the intended use of the copy). > > On other filesystems this userspace behavior might trigger the opposite > of the intended kernel behavior, causing reflink to always fall back to > simple copy because the dst inode's nodatacow attribute is set. > > Ideally btrfs will not force coreutils to do one thing on btrfs and the > opposite thing on other filesystems, so it might be worthwhile to hack > around this in the kernel as proposed above. There is precedent for > that--btrfs falls back to simple copy in reflinks of inline extents, > more or less for the sole purpose of making cp --reflink=always not fail > so randomly. > > > > Kernel version: Linux archlinux 5.12.8-arch1-1 #1 SMP PREEMPT Fri, 28 > > > May 2021 15:10:20 +0000 x86_64 GNU/Linux > > > Coreutils version: 8.32 > > > > > > Regards, > > > Tom
bug-coreutils@HIDDEN:bug#48833; Package coreutils.
Full text available.Received: (at submit) by debbugs.gnu.org; 4 Jun 2021 21:58:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 04 17:58:21 2021 Received: from localhost ([127.0.0.1]:47987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1lpHpb-0002ZH-Ch for submit <at> debbugs.gnu.org; Fri, 04 Jun 2021 17:58:21 -0400 Received: from lists.gnu.org ([209.51.188.17]:50830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <postmaster@HIDDEN>) id 1lpGFA-0000Dz-TH for submit <at> debbugs.gnu.org; Fri, 04 Jun 2021 16:16:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38838) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>) id 1lpGFA-0000QD-L2 for bug-coreutils@HIDDEN; Fri, 04 Jun 2021 16:16:36 -0400 Received: from james.kirk.hungrycats.org ([174.142.39.145]:43136) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>) id 1lpGF8-0007xD-LS for bug-coreutils@HIDDEN; Fri, 04 Jun 2021 16:16:36 -0400 Received: by james.kirk.hungrycats.org (Postfix, from userid 1002) id D80C1A8CE2E; Fri, 4 Jun 2021 16:16:31 -0400 (EDT) Date: Fri, 4 Jun 2021 16:16:31 -0400 From: Zygo Blaxell <ce3g8jdj@HIDDEN> To: Tom Yan <tom.ty89@HIDDEN> Subject: Re: reflink copying does not check/set No_COW attribute and fail Message-ID: <20210604201630.GH11733@HIDDEN> References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN> <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN> User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: pass client-ip=174.142.39.145; envelope-from=postmaster@HIDDEN; helo=james.kirk.hungrycats.org X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 04 Jun 2021 17:58:17 -0400 Cc: bug-coreutils@HIDDEN, linux-btrfs@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) On Fri, Jun 04, 2021 at 10:37:35PM +0800, Tom Yan wrote: > Also cc'ing bug-coreutils@HIDDEN > > On Fri, 4 Jun 2021 at 22:33, Tom Yan <tom.ty89@HIDDEN> wrote: > > > > Hi all, > > > > I've just bumped into a problem that I am not sure what the expected > > behavior should be, but there seems to be something flawed. > > > > Say I have a file that was created with the No_COW attributed > > (inherited from the directory / subvolume / mount option). Then if I > > try to do a reflink copy, the copying will fail with "Invalid > > argument" if the copy has no one to inherit the No_COW attribute from. Correct. nodatacow implies nodatasum, and you cannot reflink an extent from a nodatasum inode into a datasum inode. The result of allowing this would be a file that has some extents that have csums, and some that do not. Making this work would make reading from such a file worse (i.e. make it slower, or fail to detect corruption in metadata). It's possible to solve some of those problems (or at least contain them in inodes that are known to have mixed csum and non-csum data), but first someone would have to make the case that this is worth the effort to support. > > For example: > > [tom@archlinux mnt]$ sudo btrfs subvol list . > > ID 256 gen 11 top level 5 path a > > ID 257 gen 9 top level 5 path b > > [tom@archlinux mnt]$ lsattr > > ---------------------- ./a > > ---------------C------ ./b > > [tom@archlinux mnt]$ lsattr b/ > > ---------------C------ b/test > > [tom@archlinux mnt]$ du -h b/test > > 512M b/test > > [tom@archlinux mnt]$ lsattr a/ > > [tom@archlinux mnt]$ cp --reflink=always b/test a/ > > cp: failed to clone 'a/test' from 'b/test': Invalid argument > > [tom@archlinux mnt]$ lsattr a/ > > ---------------------- a/test > > [tom@archlinux mnt]$ du a/test > > 0 a/test > > [tom@archlinux mnt]$ du --apparent-size a/test > > 0 a/test > > [tom@archlinux mnt]$ rm a/test > > [tom@archlinux mnt]$ sudo chattr +C a/ > > [tom@archlinux mnt]$ cp --reflink=always b/test a/ > > [tom@archlinux mnt]$ lsattr a/ > > ---------------C------ a/test > > [tom@archlinux mnt]$ cmp b/test a/test > > [tom@archlinux mnt]$ > > > > I'm not entirely sure if a reflink copy is supposed to work for a > > source file that was created with No_COW, but apparently it is. Snapshots are also allowed for nodatacow files. The extents that are shared become implicitly datacow until they are not shared any more. Snapshots are deferred reflink copies, so it would be difficult to allow one and not the other. Disallowing both seems overly restrictive (e.g. with such a restriction, it would not be possible to use 'btrfs send' or make a snapshot on a subvol that contains any nodatacow file). btrfs did disallow both operations for swap files, so it could be possible to disallow both reflinks and snapshots for nodatacow files, but AFAIK nobody wants that (some people even want the swapfile restrictions to go away someday). > > The > > problem is just that the reflink copy also needs to have the attribute > > set, yet it cannot inherit from the source automatically. reflink can only reflink copy from one nodatasum file to another nodatasum file, or from one datasum file to another datasum file. An empty inode can be changed from datacow to nodatacow (or vice versa) using the fsattr ioctl, which simultaneously changes the file from datasum to nodatasum if the filesystem was not mounted with the nodatasum mount option. There is a possible kernel enhancement here: when an empty inode is the dst of a reflink, automatically change the reflink dst inode's nodatasum flag to match the reflink src inode's nodatasum flag. If the dst inode is not empty and the inode datasum flags do not match, then reject the reflink with EINVAL as before. It's not clear whether this should apply only to nodatasum or also to nodatacow. reflink doesn't need src and dst agreement on nodatacow, so the dst inode could be a nodatasum+datacow file. Unfortunately all the userspace tools including coreutils can only see the nodatacow inode bit, not the nodatasum bit, so the lack of csums on the dst file would be invisible. The kernel cannot know the user's intent from the available information. It's not clear that we want the kernel to be implicitly changing inode attribute bits like this--especially bits that disable integrity features like nodatasum. There is precedent for changing fsattrs with the no-compress inode flag, but that flag doesn't disable csums, and this one would. One could also make the opposite case: it should always be an error to do anything that would put data in a datasum file without csums, the existing behavior is correct, and should not be changed. The problem with this argument is that users can't see the datasum inode bits, so it's not clear that the EINVAL is a data protection mechanism. > > I wonder if this is a kernel-side problem or something that coreutils > > missed? It also seems wrong that when it fails there will be an empty > > destination file created. Normally coreutils will fall back to simple copy if --reflink=auto is used. --reflink=always is the user's explicit request for "reflink or nothing, please." The user correctly got nothing, as requested. On other filesystems, reflink on a nodatacow file might make a simple copy in the kernel--in which case you are no better off than if you had used --reflink=auto. coreutils could propagate the source inode nodatacow fsattribute to the destination inode if it intends to use reflink to copy the data. That would be the userspace equivalent of the kernel enhancement I suggested above. It would probably match user expectations better--no hidden surprises for non-coreutils use cases, and all the affected inode attribute bits are necessarily visible in userspace. fsattr propagation could be quite complicated for coreutils to implement correctly in general, as some fsattrs should not be propagated this way, and other filesystems may have different restrictions. Some fsattrs must be set before the data is written (e.g. -c for compression), others must be set after the data is written (e.g. -i for immutable), and some are a matter of user intent (e.g. should a simple copy be compressed if the source is not? Depends on the intended use of the copy). On other filesystems this userspace behavior might trigger the opposite of the intended kernel behavior, causing reflink to always fall back to simple copy because the dst inode's nodatacow attribute is set. Ideally btrfs will not force coreutils to do one thing on btrfs and the opposite thing on other filesystems, so it might be worthwhile to hack around this in the kernel as proposed above. There is precedent for that--btrfs falls back to simple copy in reflinks of inline extents, more or less for the sole purpose of making cp --reflink=always not fail so randomly. > > Kernel version: Linux archlinux 5.12.8-arch1-1 #1 SMP PREEMPT Fri, 28 > > May 2021 15:10:20 +0000 x86_64 GNU/Linux > > Coreutils version: 8.32 > > > > Regards, > > Tom
bug-coreutils@HIDDEN:bug#48833; Package coreutils.
Full text available.Received: (at submit) by debbugs.gnu.org; 4 Jun 2021 14:37:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 04 10:37:51 2021 Received: from localhost ([127.0.0.1]:47664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1lpAxL-0004xZ-4p for submit <at> debbugs.gnu.org; Fri, 04 Jun 2021 10:37:51 -0400 Received: from lists.gnu.org ([209.51.188.17]:50632) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <tom.ty89@HIDDEN>) id 1lpAxJ-0004xQ-W9 for submit <at> debbugs.gnu.org; Fri, 04 Jun 2021 10:37:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50548) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <tom.ty89@HIDDEN>) id 1lpAxJ-0003Aj-PJ for bug-coreutils@HIDDEN; Fri, 04 Jun 2021 10:37:49 -0400 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]:33663) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <tom.ty89@HIDDEN>) id 1lpAxI-0006TZ-3c for bug-coreutils@HIDDEN; Fri, 04 Jun 2021 10:37:49 -0400 Received: by mail-lf1-x12c.google.com with SMTP id t7so7317006lff.0 for <bug-coreutils@HIDDEN>; Fri, 04 Jun 2021 07:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Q3DAHo7o8uTZmmTsRSGNgAAzhtDAUn7kjhQPFCrNbU=; b=q3FKQka587yDspxjq+rl2r12tVoeSBBvM0yYDb3B+nS6GkRZNcQmbTF7sIjcCFS4Ec y0idM4sRgNxyzlgkPJplp6zBdg8A8v1F2Hd0D2KwS9uv//JKccK7pP4scW4X+ADWgUDc b+4RgsbYRGtbVr8F7XpPlgsfNSmwWt2tNVh2AjzOm9/3yk6R6kt8kGZDE06wUpxb0ZlC m0VzXIMfT0aeZVqeCboIxpGP70TE82907SpJSfrVhDfeWHC1mFpwCayPbNpsUNp6vufx Sp5W+/5M77/uEubekpWHCOgQzeL8xbTdHsAd2PI1JTWZw9KItzRP0y8huDo4FiX/uz08 HYVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0Q3DAHo7o8uTZmmTsRSGNgAAzhtDAUn7kjhQPFCrNbU=; b=NmkjWd1uiZEzT4TcsmTBxwp9jdXzIDYcaXPu2yijacyZG91PdDlpXfIs7zQ0zcT4X+ lwu6JWL1QMstU2HqvxvOgV4u0upl1BIhKeBsWivuYo0NEXK+DVz2/X1demBiUZvaZjjO BWKRmQQsctXaVVFFY2cTDwBMZXfPFezsV+I6yHTgb2sIPDqQ8mGXj7PD4f2FY+mkXsCJ I8wkLqo2OZ24to+LOU4yHuCF6s+6jqUC87xjQb+aIgy/YgAYAXnwcQP53VGYbrAWKMo9 hgEZNr3T+8ea3THNbTHwZtXWgXM1QgqvxkGCJWIrphlr0nYPKVFPxPNuuiLkjsXrHOes aICw== X-Gm-Message-State: AOAM530DM+1M4IeJf/Sel0h7t0fjnCBm5toZD4eomw1lZxeIb6WggLPW 5DDzr8s2CLwLApa2ht5mykWxlN/nLGJWS6gXgo+y5MFdTkY= X-Google-Smtp-Source: ABdhPJwRIfDKRHR1x+IXcRyi6WnOSOoR3c5FL30hTTPxHIS5RJPOsGpKuT4f3OsIoTMqWxI91N6iJz7w1YMBWZpWBJE= X-Received: by 2002:ac2:55a7:: with SMTP id y7mr2992309lfg.112.1622817465963; Fri, 04 Jun 2021 07:37:45 -0700 (PDT) MIME-Version: 1.0 References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN> In-Reply-To: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN> From: Tom Yan <tom.ty89@HIDDEN> Date: Fri, 4 Jun 2021 22:37:35 +0800 Message-ID: <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN> Subject: Re: reflink copying does not check/set No_COW attribute and fail To: linux-btrfs@HIDDEN Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::12c; envelope-from=tom.ty89@HIDDEN; helo=mail-lf1-x12c.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: submit Cc: bug-coreutils@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.1 (--) Also cc'ing bug-coreutils@HIDDEN On Fri, 4 Jun 2021 at 22:33, Tom Yan <tom.ty89@HIDDEN> wrote: > > Hi all, > > I've just bumped into a problem that I am not sure what the expected > behavior should be, but there seems to be something flawed. > > Say I have a file that was created with the No_COW attributed > (inherited from the directory / subvolume / mount option). Then if I > try to do a reflink copy, the copying will fail with "Invalid > argument" if the copy has no one to inherit the No_COW attribute from. > > For example: > [tom@archlinux mnt]$ sudo btrfs subvol list . > ID 256 gen 11 top level 5 path a > ID 257 gen 9 top level 5 path b > [tom@archlinux mnt]$ lsattr > ---------------------- ./a > ---------------C------ ./b > [tom@archlinux mnt]$ lsattr b/ > ---------------C------ b/test > [tom@archlinux mnt]$ du -h b/test > 512M b/test > [tom@archlinux mnt]$ lsattr a/ > [tom@archlinux mnt]$ cp --reflink=always b/test a/ > cp: failed to clone 'a/test' from 'b/test': Invalid argument > [tom@archlinux mnt]$ lsattr a/ > ---------------------- a/test > [tom@archlinux mnt]$ du a/test > 0 a/test > [tom@archlinux mnt]$ du --apparent-size a/test > 0 a/test > [tom@archlinux mnt]$ rm a/test > [tom@archlinux mnt]$ sudo chattr +C a/ > [tom@archlinux mnt]$ cp --reflink=always b/test a/ > [tom@archlinux mnt]$ lsattr a/ > ---------------C------ a/test > [tom@archlinux mnt]$ cmp b/test a/test > [tom@archlinux mnt]$ > > I'm not entirely sure if a reflink copy is supposed to work for a > source file that was created with No_COW, but apparently it is. The > problem is just that the reflink copy also needs to have the attribute > set, yet it cannot inherit from the source automatically. > > I wonder if this is a kernel-side problem or something that coreutils > missed? It also seems wrong that when it fails there will be an empty > destination file created. > > Kernel version: Linux archlinux 5.12.8-arch1-1 #1 SMP PREEMPT Fri, 28 > May 2021 15:10:20 +0000 x86_64 GNU/Linux > Coreutils version: 8.32 > > Regards, > Tom
Tom Yan <tom.ty89@HIDDEN>:bug-coreutils@HIDDEN.
Full text available.bug-coreutils@HIDDEN:bug#48833; Package coreutils.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.