Bug 1956080

Summary: cp --reflink=never no longer works as expected
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: coreutilsAssignee: Kamil Dudka <kdudka>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 34CC: admiller, jamartis, jarodwilson, kdudka, kzak, ooprala, ovasik, p, sebastian.kisela, svashisht
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: coreutils-8.32-24.fc34 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-11-23 15:10:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
strace cp --reflink=never none

Description Chris Murphy 2021-05-02 15:49:53 UTC 
Description of problem:

cp --reflink=never creates shared extents


Version-Release number of selected component (if applicable):
coreutils-8.32-23.fc34.x86_64

How reproducible:
Always

Steps to Reproduce:
1. cp --reflink=never a b
2. filefrag -v a; filefrag -v b
3.

Actual results:

a and b share all extents


Expected results:

They should not be reflink copies


Additional info:

Just a guess but when I strace the command using --reflink=never I see:

copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = 65843200
copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = 0


And I see in the change log:


* Wed Mar 24 2021 Kamil Dudka <kdudka> - 8.32-20
- cp: use copy_file_range if available

So I wonder if there isn't a reflink=never exception to that change?
Comment 1 Chris Murphy 2021-05-02 16:02:27 UTC 
Created attachment 1778596 [details]
strace cp --reflink=never
Comment 2 Chris Murphy 2021-05-02 16:14:47 UTC 
Problem does not happen with 
coreutils-8.32-19.fc34.x86_64.rpm
coreutils-common-8.32-19.fc34.x86_64.rpm

Problem does happen with
coreutils-8.32-20.fc34.x86_64.rpm
coreutils-common-8.32-20.fc34.x86_64.rpm
Comment 3 Chris Murphy 2021-05-02 18:17:53 UTC 
Upstream bug report:
https://lists.gnu.org/archive/html/bug-coreutils/2021-05/msg00001.html
Comment 4 Kamil Dudka 2021-05-03 09:02:22 UTC 
Thank you for debugging it and reporting it upstream!

We need to backport the following upstream commit to fix it:

https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.32-147-gea9af9923
Comment 5 Kamil Dudka 2021-05-03 12:01:13 UTC 
dist-git commits:
https://src.fedoraproject.org/rpms/coreutils/c/3a336cf37e1ded55f6c9c835ea527074a4e876e0?branch=rawhide
https://src.fedoraproject.org/rpms/coreutils/c/5985282d0541a9db2c0de830bbafceea8dcbeed2?branch=f34
Comment 6 Fedora Update System 2021-05-03 12:09:59 UTC 
FEDORA-2021-893a614857 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-893a614857
Comment 7 Fedora Update System 2021-05-04 01:09:01 UTC 
FEDORA-2021-893a614857 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-893a614857`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-893a614857

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 8 Fedora Update System 2021-05-06 01:01:30 UTC 
FEDORA-2021-893a614857 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.