Bug 2187312

Summary: SEEK_HOLE on BTRFS is treating some just written data as holes
Product: [Fedora] Fedora Reporter: Pádraig Brady <p>
Component: kernelAssignee: Josef Bacik <josef>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 37CC: acaringi, adscvr, airlied, alciregi, bskeggs, fdmanana, hdegoede, hpa, jarodwilson, jglisse, jim, josef, kernel-maint, lgoncalv, linville, masami256, mchehab, ptalbert, steved
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-04-17 21:27:16 UTC Type: ---
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
repro none

Description Pádraig Brady 2023-04-17 12:49:38 UTC 
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0
Build Identifier: 

using cp to copy a sparse file treats some none sparse parts as sparse, resulting in data corruption in the copy. The size of the copy is correct, just that some of the extents are zeros when they should not be. Repro script is attached and usually triggers within a minute. Note if the sparse file is sync'd with the sync command before the copy, then there is no corruption.

Reproducible: Sometimes

Steps to Reproduce:
1.Just run the attached script on BTRFS
Actual Results:  
script exits with error message

Expected Results:  
script runs forever
Comment 1 Pádraig Brady 2023-04-17 12:51:03 UTC 
Note the versions / settings on this machine are:

$ uname -a
Linux fedora 6.1.6-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Jan 14 16:55:06 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

$ df -Th .
Filesystem                                            Type   Size  Used Avail Use% Mounted on
/dev/mapper/luks-453ccafd-e054-4cab-8e60-d88256429112 btrfs  238G   11G  226G   5% /home

$ grep home /proc/mounts
/dev/mapper/luks-453ccafd-e054-4cab-8e60-d88256429112 /home btrfs rw,seclabel,relatime,compress=zstd:1,ssd,space_cache=v2,subvolid=256,subvol=/home 0 0
Comment 2 Pádraig Brady 2023-04-17 12:52:22 UTC 
Created attachment 1957851 [details]
repro
Comment 3 Filipe Manana 2023-04-17 18:23:10 UTC 
Can you try with a 6.2 kernel?

I'm unable to reproduce on a 6.3-rcX kernel, with coreutils 9.2 (so cp uses SEEK_HOLE and not fiemap).

Some changes happened in 6.2 that may have accidentally fixed the problem you are running into.
These are the 6.2 changes:  https://lore.kernel.org/linux-btrfs/cover.1668166764.git.fdmanana@suse.com/

Thanks.
Comment 4 Pádraig Brady 2023-04-17 21:26:48 UTC 
I can NOT repro on a 6.2 kernel.
So Fedora is fine I suppose since all Fedora now have a 6.2 kernel as their stable kernel.

For completeness the problematic combo is: coreutils >= 9.0, kernel <= 6.1, BTRFS, sparse input file